On Fri, 16 Jul 2021, Khem Raj wrote:
> On Fri, Jul 16, 2021 at 12:10 PM Robert P. J. Day
> wrote:
> >
> >
> > colleague just asked me what it would take to generate an image
> > where the executables and libraries contain all the gdb-related
> > debugging info in the same files (that is, not b
On Fri, Jul 16, 2021 at 12:10 PM Robert P. J. Day wrote:
>
>
> colleague just asked me what it would take to generate an image
> where the executables and libraries contain all the gdb-related
> debugging info in the same files (that is, not broken out in the
> .debug directories).
>
> i point
colleague just asked me what it would take to generate an image
where the executables and libraries contain all the gdb-related
debugging info in the same files (that is, not broken out in the
.debug directories).
i pointed out that this would increase the size of the installable
target image
Drop this, a second iteration is now on the list.
Ross
On Fri, 16 Jul 2021 at 15:26, Alexandre Belloni
wrote:
>
> Hi Ross,
>
> This broke at least non-gpl3:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/75/builds/3691/steps/11/logs/stdio
>
> On 16/07/2021 13:24:07+0100, Ross Burton w
This reverts part of oe-core eecbe62555, which was a previous attempt
to solve the Y2038 problem. This is now solved centrally in e2fsprogs,
so doesn't need to be dealt with in wic.
We don't revert the commit entirely, to retain the warning if a
filesystem has small inodes.
Signed-off-by: Ross B
e2fsprogs calls filesystems larger than 3MB but smaller than 512MB
"small", which has some implications:
- blocksize 1024 instead of 4096
- inode_ratio 4096 instead of 16384
- inode_size 128 instead of 256
The outcome of the inode size dropping to 128 bytes is that they cannot
store 64-bit timest
Hello all,
Can someone please clarify expected behavior of 'devtool modify virtual/kernel'
when the kernel recipe has an additional SRC_URI entry for the kernel-metadata
repository? For example, the 2021.1 linux-xlnx recipe in the meta-xilinx-bsp
layer (part of meta-xilkinx) uses the following:
Since oe-core 543e39ad "bitbake.conf: handle cmake -dev files packaging
with default rules" (June 2018) there's no need for recipes to add
${libdir}/cmake or ${datadir}/cmake to FILES_${PN}-dev themselves.
Signed-off-by: Ross Burton
---
meta/recipes-core/dbus/dbus_1.12.20.bb
Hi Ross,
This broke at least non-gpl3:
https://autobuilder.yoctoproject.org/typhoon/#/builders/75/builds/3691/steps/11/logs/stdio
On 16/07/2021 13:24:07+0100, Ross Burton wrote:
> mkfs.ext4 has logic where "small" file systems use "good old" 128-byte
> inodes instead of the default 256-byte inode
Thanks Trevor! my next world build will be green again (maybe) :).
On Fri, Jul 16, 2021 at 3:32 PM Trevor Gamblin
wrote:
>
> On 2021-07-15 2:55 p.m., Khem Raj wrote:
> > [Please note: This e-mail is from an EXTERNAL e-mail address]
> >
> > On Thu, Jul 15, 2021 at 10:57 AM Konrad Weihmann
> wrot
On Wednesday 07 July 2021 at 18:06:07 +0100, Richard Purdie wrote:
> This changes behaviour when LICENSE_CREATE_PACKAGE is in use. Packages
> no longer have RRECOMMENDS adding to them.
>
> It was highlighted that this doesn't apply to PACKAGES_DYNAMIC, nor can
> it easily be made to do so. There i
On 2021-07-15 2:55 p.m., Khem Raj wrote:
[Please note: This e-mail is from an EXTERNAL e-mail address]
On Thu, Jul 15, 2021 at 10:57 AM Konrad Weihmann wrote:
On 15.07.21 19:22, Khem Raj wrote:
On 7/15/21 7:43 AM, Martin Jansa wrote:
On Mon, Jul 12, 2021 at 9:57 AM wangmy mailto:wan...@fuj
mkfs.ext4 has logic where "small" file systems use "good old" 128-byte
inodes instead of the default 256-byte inodes. This means that small
filesystems are not 2038-safe as they only support 32-bit timestamps.
However, "small" is defined as "less than 500MB", which is a fair number
of filesystems
At the time of writing the qemu kernels don't support vfat filesystems.
There are patches on the list to add that, but as two tests fail without
vfat support, make them skip if vfat isn't available.
[ YOCTO #14470 ]
Signed-off-by: Ross Burton
---
.../parted/files/check-vfat.patch |
The recipe was using =, which replaces the default RRECOMMENDS from
ptest.bbclass.
Signed-off-by: Ross Burton
---
meta/recipes-extended/parted/parted_3.4.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-extended/parted/parted_3.4.bb
b/meta/recipes-extended/par
We've had recipe-specific sysroots for a long time now, so there's no
need to forcible disable floating checks.
Signed-off-by: Ross Burton
---
.../parted/files/no_check.patch | 20 ---
meta/recipes-extended/parted/parted_3.4.bb| 1 -
2 files changed, 21 deletio
We encountered a blueman-applet segfault with libffi 3.4.2:
$ blueman-applet
blueman-applet 01.58.45 WARNING PluginManager:148 __load_plugin: Not loading
DhcpClient because its conflict has higher priority
blueman-applet 01.58.45 WARNING TransferService:189 _make_share_path: Failed
to get Downl
enabled by default in
libffi 3.4.2. However it doesn't work with gobject-introspection[1].
[1]
https://github.com/libffi/libffi/commit/132699b95d3ee4d889ea2a80540acf3300987dad
(LOCAL REV: NOT UPSTREAM) -- Sent to oe-core on 20210716
Signed-off-by: Yi Zhao
---
meta/recipes-support/l
with gobject-introspection[1].
[1]
https://github.com/libffi/libffi/commit/132699b95d3ee4d889ea2a80540acf3300987dad
(LOCAL REV: NOT UPSTREAM) -- Sent to oe-core on 20210716
Signed-off-by: Yi Zhao
---
meta/recipes-support/libffi/libffi_3.4.2.bb | 2 +-
1 file changed, 1 insertion(+), 1 del
19 matches
Mail list logo
