On Sat, Jan 26, 2019 at 5:11 PM Khem Raj wrote:
>
> On Sat, Jan 26, 2019 at 3:27 PM Richard Purdie
> wrote:
> >
> > On Thu, 2019-01-24 at 22:35 +, Alistair Francis wrote:
> > > I don't see circular dependencies anymore between libusb1 and udev,
> > > so
> > > enable udev support for libusb1.
On Sat, Jan 26, 2019 at 3:27 PM Richard Purdie
wrote:
>
> On Thu, 2019-01-24 at 22:35 +, Alistair Francis wrote:
> > I don't see circular dependencies anymore between libusb1 and udev,
> > so
> > enable udev support for libusb1.
> >
> > Signed-off-by: Alistair Francis
> > ---
> >
Devtool needs to execute these tasks so we cannot disable them but if
SRC_URI is empty we don't need to disable them anymore. Setting
EXTERNALSRC so devshell can find the shared gcc sources.
The following changes since commit 083817577de9b55bf561c926a8948d0fc4988626:
meta-yocto-bsp: Bump to the
Devtool needs to execute these tasks so we cannot disable them
but if SRC_URI is empty we don't need to disable them anymore.
Setting EXTERNALSRC so devshell can find the shared gcc sources.
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13036
Signed-off-by: Tomasz Dziendzielski
---
On Thu, 2019-01-24 at 22:35 +, Alistair Francis wrote:
> I don't see circular dependencies anymore between libusb1 and udev,
> so
> enable udev support for libusb1.
>
> Signed-off-by: Alistair Francis
> ---
> meta/recipes-support/libusb/libusb1_1.0.22.bb | 7 ---
> 1 file changed, 4
On Tue, 2019-01-22 at 11:03 +0800, Xulin Sun wrote:
> To avoid issue like below if run "bitbake lib32-core-image-minimal"
> with series userspace packages(LAMP,krb5...) added.
>
> Add multilib_script support for openssl's c_rehash which is a perl
> script.
>
> Error: Transaction check error:
>
This is a limitation of libtool where it is not aware of compiler-rt
being a compiler internal library, this patch fixes it
Signed-off-by: Khem Raj
---
.../libtool/libtool-2.4.6.inc | 1 +
...r-static-libs-for-internal-compiler-.patch | 37 +++
2 files changed,
On Sat, Jan 26, 2019 at 1:04 PM Martin Jansa wrote:
>
> > 2. Just use -mcpu and do not use -march/-mtune and may be provide
> > mechanism to override -mcpu, which is done by packages anyway ( maps
> > directly to package architectures )
>
> This would be my preferred solution, I know that tune
> 2. Just use -mcpu and do not use -march/-mtune and may be
provide mechanism to override -mcpu, which is done by packages anyway (
maps directly to package architectures )
This would be my preferred solution, I know that tune files are already
quite complicated, but another variable which will
If kernel source is not already downloaded i.e staging kernel dir is
empty, place a copy of the source when the user runs devtool modify linux-yocto.
This way the kernel source is available for other packages that use it.
[YOCTO #10416]
Signed-off-by: Sai Hari Chandana Kalluri
Signed-off-by:
On Sat, Jan 26, 2019 at 9:39 AM Martin Jansa wrote:
>
> Which -mcpu/-march combination is causing issue in gcc9?
Its when using cortex-a5 tunes, -march=armv7-a -mcpu=cortex-a5, but if
we move the needle to fix the issue or test coverage then we miss the
point here, the fact that this keeps
Which -mcpu/-march combination is causing issue in gcc9?
I know we had this issue with armv7a tunes before, that's why I've added
separate armv7ve before the switch from -mtune to -mcpu.
I still believe -mcpu (with or without -march) is better option.
Using -mtune without indicating which
On Fri, Jan 25, 2019 at 12:32 PM Mark Hatle
wrote:
>
> On 1/24/19 9:22 PM, Khem Raj wrote:
> > On Wed, Jan 23, 2019 at 6:11 PM Andre McCurdy
wrote:
> >>
> >> On Wed, Jan 23, 2019 at 2:50 PM Khem Raj wrote:
> >>>
> >>> On Wed, Jan 23, 2019 at 5:27 PM Andre McCurdy
wrote:
>
> On Wed,
Commit 7cb42ae87ef9 "dhcp: update 4.4.1" dropped
0008-tweak-to-support-external-bind.patch
from recipe, but left the patch itself in source tree.
Remove this patch since nobody uses it.
Cc: Armin Kuster
Signed-off-by: Ruslan Bilovol
---
.../dhcp/0008-tweak-to-support-external-bind.patch | 117
Commit 68552c353255 "perl: remove the previous version of the recipe"
dropped 0001-Makefile.SH-Pod-Simple-requires-Getopt-Long.patch
from recipe, but left the patch itself in source tree.
Remove this patch since nobody uses it.
Cc: Alexander Kanavin
Signed-off-by: Ruslan Bilovol
---
Commit 5bb47984af79 "subversion: 1.9.7 -> 1.10.0" dropped
serf.m4-Regex-modified-to-allow-D-in-paths.patch
from recipe, but left the patch itself in source tree.
Remove this patch since nobody uses it.
Cc: Richard Purdie
Signed-off-by: Ruslan Bilovol
---
Commit 85b76e52d206 "connman: update to 1.36" dropped
0001-inet-Add-prefixlen-to-iproute_default_function.patch
from recipe, but left the patch itself in source tree.
Remove this patch since nobody uses it.
Cc: Oleksandr Kravchuk
Signed-off-by: Ruslan Bilovol
---
Commit "c37207d0aca5 bind: update to ESV version 9.11.3" dropped
0001-build-use-pkg-config-to-find-libxml2.patch
from recipe, but left the patch itself in source tree.
Remove this patch since nobody uses it.
Cc: Armin Kuster
Signed-off-by: Ruslan Bilovol
---
Commit "f63965c0f9fc lttng: uprev to 2.10.7" dropped
0001-Fix-btrfs-Remove-unnecessary-fs_info-parameter.patch
from recipe, but left the patch itself in source tree.
Remove this patch since nobody uses it.
Cc: Bruce Ashfield
Signed-off-by: Ruslan Bilovol
---
Working with recent oe-core I noticed that there are
patches not used by any recipe, which is confusing.
This is caused by mistakes in recipe upgrades, when
people remove patch from SRC_URI but forgets to
delete actual patch.
Instead of fixing only recipes I worked on,
I wrote a simple bash script
This function use 'return' instead of 'return None', so I updated a comment.
The following changes since commit 1979d9162a335b7d4718a6697ca57bfa16237f0e:
bitbake: gitsmy.py: Fix unpack of submodules of submodules
(2019-01-24 17:45:49 +)
are available in the Git repository at:
If it's not a patch the function returns nothing.
Signed-off-by: Tomasz Dziendzielski
---
meta/lib/oe/patch.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/lib/oe/patch.py b/meta/lib/oe/patch.py
index 07a40fc50e..8c8e96a2dc 100644
--- a/meta/lib/oe/patch.py
+++
On Sat, 2019-01-26 at 11:47 +0100, Tomasz Dziendzielski wrote:
> sob., 26 sty 2019 o 11:34 Richard Purdie
> napisał(a):
> > On Fri, 2019-01-25 at 20:55 +0100, Tomasz Dziendzielski wrote:
> > > If a SRC_URI content ends with '.patch' bitbake is
> > > trying to apply it as it's a patch file.
> > >
sob., 26 sty 2019 o 11:34 Richard Purdie
napisał(a):
>
> On Fri, 2019-01-25 at 20:55 +0100, Tomasz Dziendzielski wrote:
> > If a SRC_URI content ends with '.patch' bitbake is
> > trying to apply it as it's a patch file.
> >
> > It causes that if we use git repository for 'patch' package
> > the
On Fri, 2019-01-25 at 20:55 +0100, Tomasz Dziendzielski wrote:
> If a SRC_URI content ends with '.patch' bitbake is
> trying to apply it as it's a patch file.
>
> It causes that if we use git repository for 'patch' package
> the bare clone is extracted to a directory
> (i.e.
On Thu, 2019-01-24 at 22:22 -0500, Khem Raj wrote:
> On Wed, Jan 23, 2019 at 6:11 PM Andre McCurdy
> wrote:
> > On Wed, Jan 23, 2019 at 2:50 PM Khem Raj
> > wrote:
> > > On Wed, Jan 23, 2019 at 5:27 PM Andre McCurdy <
> > > armccu...@gmail.com> wrote:
> > > > On Wed, Jan 23, 2019 at 12:05 PM
26 matches
Mail list logo
