Polite ping.
On 23/04/2024 11.57, Rasmus Villemoes via lists.openembedded.org wrote:
> From: Rasmus Villemoes
>
> Commit 6c2ae2346db0 (kern-tools: depend on git-replacement-native)
> broke our kernel builds. For saving space and time, we have a DL_DIR
> shared between multiple
On 24/04/2024 10.36, Alexander Kanavin via lists.openembedded.org wrote:
> On Wed, 24 Apr 2024 at 10:19, Christian B. Sørensen via
> lists.openembedded.org
> wrote:
>
>> Any input on the patchset ? Would appreciate if it could be included in the
>> scarthgap release.
>
> A little patience
From: Rasmus Villemoes
Commit 6c2ae2346db0 (kern-tools: depend on git-replacement-native)
broke our kernel builds. For saving space and time, we have a DL_DIR
shared between multiple users/buildbots, not all of which run with the
same uid (and with appropriate sticky bits set so that files
On 19/04/2024 23.00, Alexander Kanavin wrote:
> This was already proposed, and rejected.
> https://lists.openembedded.org/g/openembedded-core/topic/104753355
>
> You need to fix the metadata that refers to the old name.
So, how can a layer then be compatible with both nanbield and scarthgap?
From: Rasmus Villemoes
This is very often a build dependency, such as in my case using a
class from meta-ptx, which fails with
ERROR: Nothing PROVIDES 'bmap-tools-native'. Close matches:
bmaptool-native
bpftool-native
mtools-native
due to the renaming.
Signed-off-by: Rasmus Villemoes
From: Rasmus Villemoes
Quoting 'man systemd.special':
nss-user-lookup.target
A target that should be used as synchronization point for all
regular UNIX user/group name service lookups. [...] All services
for which the availability of the full user/group database is
essential
From: Rasmus Villemoes
Building for an arm64 target, e.g. qemuarm64 or a raspberrypi3,
without "python" in PACKAGECONFIG, results in
| Makefile.config:892: *** ERROR: No python interpreter needed for jevents
generation. Install python or build with NO_JEVENTS=1.. Stop.
Signed-off-
On 06/11/2023 16.07, Richard Purdie wrote:
> On Mon, 2023-11-06 at 16:00 +0100, Rasmus Villemoes wrote:
>>
>> When I set PACKAGECONFIG for perf in a perf.bbappend file, without
>> python being in there, the build breaks:
>>
[...]
>> This difference is,
On 06/11/2023 15.49, Bruce Ashfield wrote:
> On Mon, Nov 6, 2023 at 9:22 AM Rasmus Villemoes
> wrote:
>>
>> From: Rasmus Villemoes
>>
>> Building for an arm64 target, e.g. qemuarm64 or a raspberrypi3,
>> without "python" in PACKAGECONFIG, res
Somewhat related, but maybe not really:
When I set PACKAGECONFIG for perf in a perf.bbappend file, without
python being in there, the build breaks:
| Makefile.config:277: ***
.../tmp/work/qemuarm64-poky-linux/perf/1.0/recipe-sysroot-native/usr/bin/python3-native/python3-config
not found. Stop.
From: Rasmus Villemoes
Building for an arm64 target, e.g. qemuarm64 or a raspberrypi3,
without "python" in PACKAGECONFIG, results in
| Makefile.config:892: *** ERROR: No python interpreter needed for jevents
generation. Install python or build with NO_JEVENTS=1.. Stop.
Signed-off-
From: Rasmus Villemoes
The cachegrind scripts have been rewritten in python3, so the RDEPENDS
on perl is no longer sufficient. This is unfortunately not caught by
QA checks since the scripts use
#! /usr/bin/env python3
as shebang line.
Since the valgrind binary by itself can be quite useful
From: Rasmus Villemoes
Building perf without security_flags.inc being included in one's
distro results in the buildpaths warning
WARNING: perf-1.0-r9 do_package_qa: QA Issue: File /usr/bin/trace in
package perf contains reference to TMPDIR
because the ${DEBUG_PREFIX_MAP} does not get used
On 20/10/2023 12.13, Richard Purdie wrote:
> On Fri, 2023-10-20 at 12:03 +0200, Rasmus Villemoes wrote:
>> On 20/10/2023 11.38, Richard Purdie wrote:
>>> On Fri, 2023-10-20 at 10:10 +0200, Rasmus Villemoes wrote:
>>>> On 19/10/2023 14.48, Richard Purdie wrote:
>>
On 20/10/2023 11.38, Richard Purdie wrote:
> On Fri, 2023-10-20 at 10:10 +0200, Rasmus Villemoes wrote:
>> On 19/10/2023 14.48, Richard Purdie wrote:
>>> The fact this works suggests perf is ignoring TARGET_CFLAGS. Is there
>>> anything in the perf build system
On 19/10/2023 14.48, Richard Purdie wrote:
> On Thu, 2023-10-19 at 14:32 +0200, Rasmus Villemoes via
> lists.openembedded.org wrote:
>> From: Rasmus Villemoes
>>
>> Building perf without security_flags.inc being included in one's
>> distro results in the buildpaths w
From: Rasmus Villemoes
Building perf without security_flags.inc being included in one's
distro results in the buildpaths warning
WARNING: perf-1.0-r9 do_package_qa: QA Issue: File /usr/bin/trace in
package perf contains reference to TMPDIR
because the ${DEBUG_PREFIX_MAP} does not get used
On 10/10/2023 14.31, Bruce Ashfield wrote:
>
>
> On Tue, Oct 10, 2023 at 7:44 AM Rasmus Villemoes
> It seems we can fix it with
>
> $ git diff
> diff --git a/meta/recipes-kernel/perf/perf.bb <http://perf.bb>
> b/meta/recipes-kernel/perf/perf.b
On 10/07/2023 05.20, Bruce Ashfield via lists.openembedded.org wrote:
> From: Bruce Ashfield
>
> kernel version 6.4 introduces a new file that need to have
> absolute paths removed, so we can avoid the buildpaths QA
> warning and have relocatable packages.
>
> We add pmu-flex.h to the
From: Rasmus Villemoes
Parsing sshd's config file with 'sed' does not work in for example the
case where somebody has made use of the new ability to add a config
fragment in /etc/ssh/sshd_config.d/ with one or more HostKey
stanzas. Also, sshd_config keywords are case-insensitive, but the
current
On 15/08/2023 15.08, Paul Gortmaker via lists.openembedded.org wrote:
> [Dilemma on changes - merge or not to merge (e.g. 6.4)] On 14/08/2023 (Mon
> 10:54) Richard Purdie wrote:
>
>> Remaining are:
>> * an error upon boot on preempt-rt on qemux86-64
>> (e.g.
>>
On 10/11/2022 21.32, Paul Eggleton via lists.openembedded.org wrote:
> Hi Richard
>
> On Thursday, 10 November 2022 11:14:24 NZDT Richard Purdie wrote:
>> Adding in yet further if/else paths with magic variables to control
>> them isn't filling me with confidence.
>
> I understand that. I was
-by: Rasmus Villemoes
---
meta/conf/bitbake.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index dd2df8a552..52a36d788b 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -928,7 +928,7 @@ SHELL[unexport] = &q
On 30/05/2022 11.19, Rasmus Villemoes via lists.openembedded.org wrote:
> Hi,
>
> Suppose I want to define BB_DEFAULT_UMASK in site.conf or local.conf (I
> do have a use case for setting it to 002). But bitbake.conf includes
> those files before it then goes on to use an unconditi
On 09/06/2022 09.20, Luca Ceresoli wrote:
> Hi Rasmus,
>
> On Wed, 8 Jun 2022 15:12:05 +0200
> "Rasmus Villemoes via lists.openembedded.org"
> wrote:
> ^^^
>
> As you can see above, your sender address is getting mangled. This is
>
} ().
Deferring to first boot via 'exit 1' is no longer supported.
Fix that by also alternatifying lsattr just as chattr already is.
Signed-off-by: Rasmus Villemoes
---
meta/recipes-devtools/e2fsprogs/e2fsprogs_1.46.5.bb | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/meta/recipes
On 08/06/2022 14.30, Paulo Neves wrote:
> On 6/8/22 14:13, Rasmus Villemoes wrote:
>
>> On 08/06/2022 13.58, Paulo Neves via lists.openembedded.org wrote:
> I mean that your patch allows for a new standalone package ${PN}-xxd.
> Were somebody to use this package standalon
On 08/06/2022 13.58, Paulo Neves via lists.openembedded.org wrote:
> Forgive me if it is a stupid question, but does xxd not rdepend on
> ncurses-terminfo-base as well?
No, it does not, it's a trivial standalone utility whose only dynamic
dependency is libc.
> I ask because before your patch it
vim-xxd package.
Signed-off-by: Rasmus Villemoes
---
meta/recipes-support/vim/vim_8.2.bb | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-support/vim/vim_8.2.bb
b/meta/recipes-support/vim/vim_8.2.bb
index f358e61132b..fee9f055e9a 100644
--- a/meta/recipes
Hi,
Suppose I want to define BB_DEFAULT_UMASK in site.conf or local.conf (I
do have a use case for setting it to 002). But bitbake.conf includes
those files before it then goes on to use an unconditional assignment
BB_DEFAULT_UMASK = "022"
So how/where is one supposed to be able to set
onal (with NO_EXPAT).
Setting --without-expat and --without-curl reduces the size of the
installed "git" package from 18M to 12M, in addition to avoiding
pulling those libraries into the rootfs.
Signed-off-by: Rasmus Villemoes
---
meta/recipes-devtools/git/git_2.35.1.bb | 6 --
1 fi
On 28/02/2022 14.41, Richard Purdie wrote:
> On Mon, 2022-02-28 at 09:42 +0100, Rasmus Villemoes wrote:
>> The imx-gpu-sdk recipe in the meta-imx layer references
>> ${BB_NUMBER_THREADS} in its do_compile function. Changing
>> BB_NUMBER_THREADS between bitbake invocations le
. This is inconsistent with and in contrast to
both PARALLEL_MAKE and OMP_NUM_THREADS, the latter of which even has
${BB_NUMBER_THREADS} as default value.
Signed-off-by: Rasmus Villemoes
---
meta/conf/bitbake.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/conf
the
kernel due to the setting of KERNEL_CC, and the kernel build system
itself also probes for and uses at least -fmacro-prefix-map (hence
taking care of __FILE__ etc., but not necessarily things that go in
.debug_info sections).
Signed-off-by: Rasmus Villemoes
---
meta/classes/kernel.bbclass | 15
On 06/07/2021 21.39, Alex Stewart wrote:
> Hey Rasmus,
>
> Sorry for the delay; I was OOO for the holidays and I'm just now working
> through my inbox.
No need to apologize; as it happens I've just now returned from vacation.
> On 6/28/21 4:17 AM, Rasmus Villemoes wrote:
>>
On 30/06/2021 23.19, Alexander Kanavin wrote:
> Should this be in meta-oe rather than oe-core?
Perhaps. Could you share some of your thought process that led you to
ask that question? I honestly didn't think much about it, but it did
seem to fit well with the other "userspace tools closely tied
vdsotest is a handy tool for testing and benchmarking the vDSO,
e.g. to measure the overhead of clock_gettime() done via the vDSO
compared to an actual system call.
Signed-off-by: Rasmus Villemoes
---
Resending because the list rejected the first attempt, sent from a
wrong email address
On 25/06/2021 18.13, Richard Purdie wrote:
> On Fri, 2021-06-25 at 17:45 +0200, Rasmus Villemoes wrote:
>> On 25/06/2021 14.16, Richard Purdie wrote:
>>> On Fri, 2021-06-25 at 09:37 +0200, Rasmus Villemoes via
>>> lists.openembedded.org wrote:
>>>> I
On 25/06/2021 14.16, Richard Purdie wrote:
> On Fri, 2021-06-25 at 09:37 +0200, Rasmus Villemoes via
> lists.openembedded.org wrote:
>> I noticed that if I have an image recipe that says
>>
>> IMAGE_INSTALL += "kernel-module-foo"
>>
>> it fails
I noticed that if I have an image recipe that says
IMAGE_INSTALL += "kernel-module-foo"
it fails as expected when the kernel hasn't been built with CONFIG_FOO=m.
However, if at the same time some other package which happens to get
installed in the same image says
RRECOMMENDS_${PN} +=
On 25/09/2020 15.14, Rasmus Villemoes via lists.openembedded.org wrote:
> You've convinced me that changing deltask to noexec is too
> wide-reaching, which means that I think just patch 1/4 should be
> applied. Please consider doing that.
Or rather, please apply the v2 I just sent
, breaking
the build.
We need this task to run regardless of whether do_patch exists or not,
so reinstate the configure->symlink_kernsrc dependency explicitly.
Fixes: c5dfc2586b41 (kernel.bbclass: run do_symlink_kernsrc before
do_patch)
Reported-by: Chanho Park
Signed-off-by: Rasmus Villem
On 25/09/2020 13.43, Richard Purdie wrote:
> On Fri, 2020-09-25 at 12:31 +0200, Rasmus Villemoes wrote:
>> Well, perhaps listtasks could be taught to say "[noexec flag set]" in
>> the description - currently it seems to be somewhat random whether a
>&g
On 25/09/2020 11.22, Richard Purdie wrote:
> On Fri, 2020-09-25 at 11:06 +0200, Rasmus Villemoes wrote:
>> On 22/09/2020 17.15, Rasmus Villemoes wrote:
>>> This is all entirely untested, hence RFC. But if this doesn't work
>>> for
>>> some reason, I think
On 22/09/2020 17.15, Rasmus Villemoes wrote:
> This is all entirely untested, hence RFC. But if this doesn't work for
> some reason, I think externalsrc.bbclass should grow some comments as
> to why deltask is used instead of the noexec flag.
>
> Patch 4 is a revert of pat
dangerous for backporting. If that
is considered safe enough, it should be enough to apply patch 2 to
avoid the churn. In any case, patch 3 is just a little simplification
made possible by patch 2.
Rasmus Villemoes (4):
kernel.bbclass: ensure symlink_kernsrc task gets run even
With the changes to externalsrc.bbclass to make tasks noexec instead
of deleting them, we no longer need to explicitly make
do_symlink_kernsrc a dependency of do_configure.
Signed-off-by: Rasmus Villemoes
---
meta/classes/kernel.bbclass | 5 +
1 file changed, 1 insertion(+), 4 deletions
The preferred way to prevent a task from running is not to deltask it,
but setting the noexec flag. That way various implicit dependencies
through the task in question are preserved, avoiding ad hoc
workarounds, such as the one right here.
Signed-off-by: Rasmus Villemoes
---
meta/classes
Now that SRCTREECOVEREDTASKS gets marked as noexec rather than being
deltask'ed, do_kernel_configme is still ordered after do_patch (and
recursively, after do_unpack), so this workaround is no longer needed.
Signed-off-by: Rasmus Villemoes
---
meta/classes/kernel-yocto.bbclass | 6 --
1
do_symlink_kernsrc before
do_patch)
Reported-by: Chanho Park
Signed-off-by: Rasmus Villemoes
---
meta/classes/kernel.bbclass | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 48135b3d41..78def5bbc1 100644
--- a/meta
On 16/09/2020 17.18, Steve Sakoman wrote:
> Since there is an upcoming dunfell release and we don't have a fix for
> this issue I am going to revert this patch.
>
> When it is fixed in master I will reconsider taking this patch and the
> fix for dunfell.
Sorry for not seeing this sooner, and for
On 04/09/2020 13.51, Richard Purdie wrote:
> On Fri, 2020-09-04 at 09:08 +0200, Rasmus Villemoes wrote:
>> Not every image necessarily wants a timestamp file,
>
> Wouldn't you just not have rootfs_update_timestamp in
> ROOTFS_POSTPROCESS_COMMAND in that case?
Perhaps, but r
that to the empty string opts out of
creating the timestamp file.
I wasn't sure whether to spell /etc as ${sysconfdir}, but chose /etc
to stay completely backwards compatible.
Signed-off-by: Rasmus Villemoes
---
meta/classes/rootfs-postcommands.bbclass | 9 +++--
1 file changed, 7 insertions
ndow after shutil.move and before the symlink has been
created.
Fix that by simply ordering symlink_kernsrc before do_patch. Any task
that pokes around in ${S} looking for files should be ordered after
do_patch, so this should also fix similar latent races with other ad
hoc tasks.
Signed-off-by: Rasmus
There are a couple of problems with do_populate_lic, especially around
the kernel and u-boot recipes.
First, we have a race condition in kernel recipes:
addtask populate_lic after do_patch before do_build
addtask symlink_kernsrc before do_configure after do_unpack
so there's no ordering between
On 24/08/2020 23.08, Richard Purdie wrote:
> On Mon, 2020-08-24 at 23:05 +0200, Rasmus Villemoes wrote:
>> On 22/08/2020 09.27, Richard Purdie via lists.openembedded.org wrote:
>>> On Fri, 2020-08-21 at 17:32 -0700, Tom King wrote:
>>>> What would be a use c
On 22/08/2020 09.27, Richard Purdie via lists.openembedded.org wrote:
> On Fri, 2020-08-21 at 17:32 -0700, Tom King wrote:
>> What would be a use case for cleanstate?
>
> I never really wanted to add it at all. There is/was some case for
> wanting to remove sstate objects and ensure something
On 09/07/2020 21.31, Rasmus Villemoes via lists.openembedded.org wrote:
> On 02/07/2020 08.42, Rasmus Villemoes via lists.openembedded.org wrote:
>> On 01/07/2020 16.03, Quentin Schulz wrote:
>>> Hi Rasmus,
>>>
>>> On Wed, Jul 01, 2020 at 03:51:19PM +0
.
Signed-off-by: Rasmus Villemoes
---
Those other recipes can certainly also just copy-paste find_cfgs(),
but I think it's nice to avoid even small pieces of code duplication
(it all adds up).
What does cml1 stand for? I can't find anything in git history or
comments, and "basic su
On 02/07/2020 08.42, Rasmus Villemoes via lists.openembedded.org wrote:
> On 01/07/2020 16.03, Quentin Schulz wrote:
>> Hi Rasmus,
>>
>> On Wed, Jul 01, 2020 at 03:51:19PM +0200, Rasmus Villemoes wrote:
>>> Hi,
>>>
>>> We have a recip
can always RDEPEND on coreutils-stdbuf.
Signed-off-by: Rasmus Villemoes
Signed-off-by: Richard Purdie
(cherry picked from commit 74d24b5b895198898944260136d05e991a203c11)
---
meta/recipes-core/coreutils/coreutils_8.31.bb | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --
can always RDEPEND on coreutils-stdbuf.
Signed-off-by: Rasmus Villemoes
---
meta/recipes-core/coreutils/coreutils_8.32.bb | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/coreutils/coreutils_8.32.bb
b/meta/recipes-core/coreutils/coreutils_8.3
On 04/07/2020 23.10, Adrian Bunk wrote:
> On Fri, Jul 03, 2020 at 11:48:36AM +0100, Richard Purdie wrote:
>> ...
>> I hadn't realised there was already the reverse dependency. I think we
>> need to let the package exist in both cases so the two dependencies
>> need to reverse direction depending
On 03/07/2020 12.48, Richard Purdie wrote:
>>> Whilst I realise there is a problem here is the correct fix not:
>>>
>>> RDEPENDS_coreutils-stdbuf_class-target +=
>>> "${@bb.utils.contains('PACKAGECONFIG', 'single-binary', '', 'coreutils',
>>> d)}"
>>>
>>> ?
>>
>> [Well, the coreutils should be
On 03/07/2020 11.19, Richard Purdie wrote:
> On Fri, 2020-07-03 at 09:36 +0200, Rasmus Villemoes wrote:
>> Commit 992cec44 (coreutils: Move stdbuf into an own package
>> coreutils-stdbuf) breaks package-qa when the single-binary
>> PACKAGECONFIG is used:
>>
og-shebang=stdbuf
Since there's no point splitting stdbuf to its own package when all
the functionality is in the single big coreutils binary anyway, fix
this by not creating the separate stdbuf package for the single-binary
case.
Signed-off-by: Rasmus Villemoes
---
The same issue exists in master,
On 01/07/2020 16.03, Quentin Schulz wrote:
> Hi Rasmus,
>
> On Wed, Jul 01, 2020 at 03:51:19PM +0200, Rasmus Villemoes wrote:
>> Hi,
>>
>> We have a recipe that uses
>>
>> SRC_URI += "file://somedir/*"
>>
>
> Glob aren't supported
Hi,
We have a recipe that uses
SRC_URI += "file://somedir/*"
and we have noticed that changing one of the files inside somedir does
not cause the recipe to be rebuilt - in fact, no task hashes are
affected; we discovered this because a clean build worked correctly,
while one that uses an
that actually changes generated code to add some memory
tracking] from (assume no) to (assume yes). So explicitly pass the
appropriate options that make those two have the same value as they
used to have by default.
Signed-off-by: Rasmus Villemoes
---
meta/recipes-support/curl/curl_7.70.0.bb | 3
On 04/06/2020 22.05, Andre McCurdy wrote:
> but I can try to summarise the details related to the actual patch...
[snip]
> There's a genuine bug and I don't see an obviously better fix, so I
> think the patch should be merged.
Thank you for that summary, that's much better than what I could
On 03/06/2020 22.44, Andre McCurdy wrote:
> On Wed, Jun 3, 2020 at 12:38 AM Rasmus Villemoes
> wrote:
>> On 02/06/2020 23.46, Andre McCurdy wrote:
>>> On Tue, Jun 2, 2020 at 2:15 PM Phil Blundell via
>>> lists.openembedded.org wrote:
>>>>
>>>
&g
On 02/06/2020 23.46, Andre McCurdy wrote:
> On Tue, Jun 2, 2020 at 2:15 PM Phil Blundell via
> lists.openembedded.org wrote:
>>
>> On Tue, Jun 02, 2020 at 09:17:44PM +0100, Richard Purdie wrote:
>>> I understand the concern, I am a little torn on this as adding in too
>>> many different controls
On 02/06/2020 23.15, Phil Blundell wrote:
> On Tue, Jun 02, 2020 at 09:17:44PM +0100, Richard Purdie wrote:
>> I understand the concern, I am a little torn on this as adding in too
>> many different controls and options complicates the test matrix and
>> makes things harder for users.
>>
>> You're
On 02/06/2020 19.58, Khem Raj wrote:
> On Tue, Jun 2, 2020 at 5:17 AM Rasmus Villemoes
> wrote:
>>
>> There are cases where one doesn't want ldconfig on target (e.g. for
>> read-only root filesystems, it's rather pointless), yet one still
>> needs ld.so.conf to
typos in the bb.note (add spaces) so one can just
copy-paste the line from the log-file and redo the command.
Signed-off-by: Rasmus Villemoes
---
v3: rebase to master
v2: don't delete the configuration file(s) - that's also a much
simpler patch.
meta/lib/oe/rootfs.py | 2
typos in the bb.note (add spaces) so one can just
copy-paste the line from the log-file and redo the command.
Signed-off-by: Rasmus Villemoes
---
v2: don't delete the configuration file(s) - that's also a much
simpler patch.
meta/lib/oe/rootfs.py | 2 +-
meta/recipes-core/glibc
On 18/05/2020 14.29, Andreas Oberritter wrote:
> Hello Rasmus,
>
> On Mon, 18 May 2020 14:12:43 +0200
> Rasmus Villemoes wrote:
>
>> I'm certainly open to other ways of solving this. But can we agree that
>> it is a bug that the ldconfig done at build-time does no
On 18/05/2020 13.55, Martin Jansa wrote:
> This won't work, because as soon as glibc is upgraded with package
> management, the ldconfig files will be restored and there won't be any
> do_rootfs hook to remove it.
>
> Why isn't ldconfig installed in your setup in first place? RRECOMMENDS
> should
serve no purpose at run-time.
While here, fix a typo in the bb.note so one can just copy-paste the
line from the log-file and redo the command.
Signed-off-by: Rasmus Villemoes
---
meta/lib/oe/rootfs.py | 11 ++-
meta/recipes-core/glibc/glibc-package.inc | 4 ++--
2
I was wondering why my U-Boot build would always report as coming from a
-dirty directory. The /git source directory was completely clean and
matched the desired commit.
But the -dirty is appended by the scripts/setlocalversion (linux uses
the same script) if
git diff-index --name-only HEAD
ping
On 20/01/2020 16.42, Khem Raj wrote:
> this patch is ok but I have reservations since += now means global
> ldflags will be applied
> so it would need some testing to ensure it works well.
>
> On Mon, Jan 20, 2020 at 1:23 AM Rasmus Villemoes
> wrote:
>>
>> T
On 20/01/2020 16.42, Khem Raj wrote:
> this patch is ok but I have reservations since += now means global
> ldflags will be applied
Indeed, that's half the point of the patch.
> so it would need some testing to ensure it works well.
Yes, but I don't think there's any way to figure out if it
Signed-off-by: Rasmus Villemoes
---
v2: Rebase to real upstream master. Note to self: "git pull" before rebasing to
master.
meta/recipes-core/glibc/glibc_2.31.bb | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/meta/recipes-core/glibc/glibc_2.31.bb
b/meta/recipes-core
Signed-off-by: Rasmus Villemoes
---
meta/recipes-core/glibc/glibc_2.30.bb | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/meta/recipes-core/glibc/glibc_2.30.bb
b/meta/recipes-core/glibc/glibc_2.30.bb
index 7913bc2812..c6dd78ca8b 100644
--- a/meta/recipes-core/glibc/glibc_2.30.bb
I've added a custom setting to TARGET_LDFLAGS, but then I noticed that
the glibc build ignored that. The glibc do_compile did
LDFLAGS = ""
for a very long time, with the explanation that "# -Wl,-rpath-link
/lib in LDFLAGS can cause breakage if another glibc is in
staging". Is that actually
from do_configure is ${STAGING_INCDIR}. Obviously that
directory does not have /lib or /usr subdirectories, so we're not
really helping the fallback logic in check_ipt_lib_dir() - in fact,
we're more or less guaranteeing that we won't find those .so files.
Signed-off-by: Rasmus Villemoes
---
v2
.
Signed-off-by: Rasmus Villemoes
---
.../iproute2/iproute2/configure-cross.patch | 32 ---
.../iproute2/iproute2_4.19.0.bb | 1 -
2 files changed, 33 deletions(-)
delete mode 100644
meta/recipes-connectivity/iproute2/iproute2/configure-cross.patch
diff --git
On 08/05/2019 16.22, mikko.rap...@bmw.de wrote:
> On Wed, May 08, 2019 at 05:07:08PM +0300, Adrian Bunk wrote:
>> On Wed, May 08, 2019 at 04:26:09PM +0300, Mikko Rapeli wrote:
>>> Since openssl 1.1.1 and openssh which uses it, sshd
>>> startup is delayed. The delays range from few seconds
>>> to
On 09/11/2018 09.54, Hongxu Jia wrote:
> Since commit [f1dc9ac rng-tools: Fix crazy defaults] fixed
> init based on sysvinit, this fix rngd.service based on systemd.
>
> Signed-off-by: Hongxu Jia
> ---
> meta/recipes-support/rng-tools/rng-tools/rngd.service | 2 +-
> 1 file changed, 1
On 09/11/2018 09.54, Hongxu Jia wrote:
> Since commit [f1dc9ac rng-tools: Fix crazy defaults] fixed
> init based on sysvinit, this fix rngd.service based on systemd.
>
> Signed-off-by: Hongxu Jia
> ---
> meta/recipes-support/rng-tools/rng-tools/rngd.service | 2 +-
> 1 file changed, 1
ping ping
On 29/12/2018 01.06, Rasmus Villemoes wrote:
> image_types_wic.bbclass has a mechanism for doing variable substitution
> on .wks files by simply letting the input file be called
> .wks.in. However, that doesn't allow using variables in files included
> via the inclu
ping
On 29/12/2018 01.06, Rasmus Villemoes wrote:
> image_types_wic.bbclass has a mechanism for doing variable substitution
> on .wks files by simply letting the input file be called
> .wks.in. However, that doesn't allow using variables in files included
> via the inclu
to
WICVARS to get them exported appropriately.
Signed-off-by: Rasmus Villemoes
---
scripts/lib/wic/ksparser.py | 17 +
1 file changed, 17 insertions(+)
diff --git a/scripts/lib/wic/ksparser.py b/scripts/lib/wic/ksparser.py
index 7e5a9c5092..08baf76123 100644
--- a/scripts/lib/wic
This does the same thing, but is more efficient in case st_nlinks
is (already) 1.
Depends on bitbake commit 7ae93cf40ab91965147055100432961436bce46c .
Signed-off-by: Rasmus Villemoes
---
meta/lib/oe/package.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/lib/oe
This does the same thing, but is more efficient in case st_nlinks
is (already) 1.
Depends on bitbake commit 7ae93cf40ab91965147055100432961436bce46c .
Signed-off-by: Rasmus Villemoes
---
meta/classes/package.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta
On 2018-07-11 16:30, Rasmus Villemoes wrote:
> MSG_NOSIGNAL has been in Linux since 2.2, and has been standardized in
> POSIX 2008. Using that when available avoids the overhead of the two
> syscalls to set and restore the SIGPIPE handler. Moreover, we can
> eliminate one write() ca
On 2018-07-17 10:13, Rasmus Villemoes wrote:
> ping...
>
ping2
> On 2018-07-11 13:38, Rasmus Villemoes wrote:
>> nativesdk-gpgme fails package_qa when setting PACKAGE_DEBUG_SPLIT_STYLE
>> = "debug-with-srcpkg".
>>
>> ERROR: nativesdk-gpgme-1.10.0-r0
busybox 1.27.2 udhcpd does not respond to SIGTERM. Backport the upstream
fix. I've verified that this makes our local automated test suite pass
again.
Signed-off-by: Rasmus Villemoes
---
.../busybox/udhcpd-fix-not-dying-on-SIGTERM.patch | 273 +
meta/recipes-core/busybox
On 2018-07-03 14:54, Rasmus Villemoes wrote:
> image_types_wic.bbclass has a mechanism for doing variable substitution
> on .wks files by simply letting the input file be called
> .wks.in. However, that doesn't allow using variables in files included
> via the inclu
ping...
On 2018-07-11 13:38, Rasmus Villemoes wrote:
> nativesdk-gpgme fails package_qa when setting PACKAGE_DEBUG_SPLIT_STYLE
> = "debug-with-srcpkg".
>
> ERROR: nativesdk-gpgme-1.10.0-r0 do_package_qa: QA Issue: non debug package
> contains .debug directory: n
1 - 100 of 111 matches
Mail list logo
