== Series Details ==
Series: glibc: Fix non-IA reproducibility for shared libraries
Revision: 1
URL : https://patchwork.openembedded.org/series/14338/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests ha
Compute a relative path to build-arm-tait-linux-gnueabi/csu/
for each library subdirectory.
Signed-off-by: Douglas Royds
---
meta/conf/bitbake.conf| 2 +-
...34-reproducible-makehack-shared-libs.patch | 48 +++
meta/recipes-core/glibc/glibc_2.28.bb
On 03/10/18 15:37, Douglas Royds wrote:
I added "realpath" to the HOSTTOOLS, and precomputed a relative path
to the csu/ dir in git/Makerules.
csu-objpfx-relative = $(shell realpath --relative-to=`pwd`
$(csu-objpfx))/
Seems to do the trick. I'll send a patch(ish) separately.
Richa
On 03/10/18 05:58, Richard Purdie wrote:
On Thu, 2018-09-27 at 12:18 +1200, Douglas Royds wrote:
When I build glibc in two different places, I get non-reproducible
results - a 4-byte difference:
$ cmp -l ~/workspace/upstream[12]/build/tmp/work/armv5e-tait-linux-
gnueabi/glibc/2.28-r0/package/l
On Wednesday, 3 October 2018 1:44:05 PM NZDT Khem Raj wrote:
> Musl started blocking dlopen of libs with initial-exec references into
> dynamic TLS area, via
>
> https://github.com/kraj/musl/commit/5c2f46a214fc3c3e41700c51415e0a4f1acd
>
> prior to that commit, musl was loading it and silently
Musl started blocking dlopen of libs with initial-exec references into
dynamic TLS area, via
https://github.com/kraj/musl/commit/5c2f46a214fc3c3e41700c51415e0a4f1acd
prior to that commit, musl was loading it and silently letting
subsequent TLS accesses via the miscompiled code clobber memory
Musl started blocking dlopen of libs with initial-exec references into
dynamic TLS area, via
https://github.com/kraj/musl/commit/5c2f46a214fc3c3e41700c51415e0a4f1acd
prior to that commit, musl was loading it and silently letting
subsequent TLS accesses via the miscompiled code clobber memory
Targeting sumo too.
Anibal
On Tue, 2 Oct 2018 at 16:43, Aníbal Limón wrote:
> When execute in multiple layers like meta-openembedded the execution is
> aborted when some sublayer fails to get world signatures, so mark it as
> an error and continue the execution in the remaining sublayers.
>
> S
When Layer A and Layer B depend on each other, then we will end up in a
recursive loop in function recurse_dependencies(). To avoid such situation
before making the recursive function call we check whether or not we have
already processed this layer.
e.g. without this patch, running this script on
When execute in multiple layers like meta-openembedded the execution is
aborted when some sublayer fails to get world signatures, so mark it as
an error and continue the execution in the remaining sublayers.
Signed-off-by: Aníbal Limón
---
scripts/yocto-check-layer | 9 -
1 file changed,
Can we have bit more detail in the commit message about what the issues are?
We're not supposed to rely solely on a bug report reference to do that; also
if it's considered a workaround and we're working with upstream to fix it, the
commit message should state that as well.
Thanks
Paul
On Wedn
Yes, will do. I think it will need some time since this needs to be
well explained so mesa devs can see the reasoning behind it
On Tue, Oct 2, 2018 at 1:42 PM Burton, Ross wrote:
>
> Can you file a bug with mesa so we don't forget and Mesa knows?
>
> Ross
> On Tue, 2 Oct 2018 at 20:37, Khem Raj w
Can you file a bug with mesa so we don't forget and Mesa knows?
Ross
On Tue, 2 Oct 2018 at 20:37, Khem Raj wrote:
>
> I think it is. The way th calls are set for performance reasons seems to be
> causing this
> Ideally we should ensure to use right dialect for tls calls I think musl is
> expos
I think it is. The way th calls are set for performance reasons seems to be
causing this
Ideally we should ensure to use right dialect for tls calls I think musl
is exposing a bug in Mesa
Which we covered by disabling tls in Glx once we disable that then this
problem pops up so we disable ASM
So
Isn't this a bit overkill? Is the assembler actually broken?
Ross
On Tue, 2 Oct 2018 at 20:21, Khem Raj wrote:
>
> some unknown part of mesa's x86 assembly
> code is broken by readonly text segments
>
> [ YOCTO #12918 ]
>
> Signed-off-by: Khem Raj
> ---
> meta/recipes-graphics/mesa/mesa.inc |
some unknown part of mesa's x86 assembly
code is broken by readonly text segments
[ YOCTO #12918 ]
Signed-off-by: Khem Raj
---
meta/recipes-graphics/mesa/mesa.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-graphics/mesa/mesa.inc
b/meta/recipes-graphics/mes
On Tue, Oct 2, 2018 at 6:13 AM Stefan Agner wrote:
>
> On 02.10.2018 10:46, Stefan Agner wrote:
> > On 26.09.2018 11:34, Stefan Agner wrote:
> >> Hi,
> >>
> >> On 12.09.2018 00:49, Stefan Agner wrote:
> >
> >> We discussed the issue at Linaro Connect a bit.
> >>
> >> To recap, we do build in two
And there's now OpenEmbedded branded Sweatshirt available (limited stock):
https://www.hellotux.com/openembedded_sweatshirt
BTW, percentage of the sales gets donated to the project. So, besides showing
your support by wearing clothing with OpenEmbedded logo, you also support the
project financia
From: Kai Kang
Add os-release to NON_MULTILIB_RECIPES in multilib.conf that do not do
multilib expand for os-release.
Signed-off-by: Kai Kang
---
meta/conf/multilib.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/conf/multilib.conf b/meta/conf/multilib.conf
index
From: Kai Kang
The first line of output of '$CC --version' is written to check_stdint.h
as a comment line. It causes multilib install file conflict.
Do not echo compiler version info to check_stdint.h to fix the issue.
Signed-off-by: Kai Kang
---
...echo-compiler-info-to-check_stdint.h.patch
From: Kai Kang
V3:
* replace sed commands with patches
* avoid multilib expand for os-release. It needs a commit on branch
master-next, so rebase on master-next
The following changes since commit 92bf8679fd1b61a90ad3694ed7be5704ad0d6353:
meta-ide-support: add cmake-native (2018-10-01 13:08:
From: Kai Kang
A comment line of conf file cups-files.conf refers to var @CUPS_SERVERBIN@
is ${libdir} related and then it causes multilib install file conflict.
Remove @CUPS_SERVERBIN@ from the comment line to avoid the conflict.
Signed-off-by: Kai Kang
---
meta/recipes-extended/cups/cups.in
From: Kai Kang
The first line of config file man_db.conf is the package name. It causes
multilib install file conflict. So add a patch to remove the line.
Signed-off-by: Kai Kang
---
...nf-avoid-multilib-install-file-conflict.patch | 16
meta/recipes-extended/man-db/man-db_2.8
On Thu, 2018-09-27 at 12:18 +1200, Douglas Royds wrote:
> When I build glibc in two different places, I get non-reproducible
> results - a 4-byte difference:
> > $ cmp -l ~/workspace/upstream[12]/build/tmp/work/armv5e-tait-linux-
> > gnueabi/glibc/2.28-r0/package/lib/libc-2.28.so
> > 1259181 71 17
The case in ptest use `nm -Pg libcrypto.so' to check symbol presence,
if library is stripped or debug split, the case will fail.
The test case needs debug symbols then we just disable that test.
Signed-off-by: Hongxu Jia
---
.../openssl/0001-skip-test_symbol_presence.patch | 46 ++
On 2018年10月02日 23:53, richard.pur...@linuxfoundation.org wrote:
On Tue, 2018-10-02 at 23:29 +0800, Kang Kai wrote:
On 2018年09月29日 20:44, Richard Purdie wrote:
On Sat, 2018-09-29 at 13:43 +0800, kai.k...@windriver.com wrote:
From: Kai Kang
There is a multilib install file conflict of nss:
fi
On 2018年10月02日 03:46, Burton, Ross wrote:
If the test case needs debug symbols then I'd suggest we just disable
that test. Especially as the test starts with this comment:
"NOTE: developer test! It's possible that it won't run on your\n",
"platform, and that's perfectly fine. This is mainly for
On Tue, 2018-10-02 at 23:29 +0800, Kang Kai wrote:
> On 2018年09月29日 20:44, Richard Purdie wrote:
> > On Sat, 2018-09-29 at 13:43 +0800, kai.k...@windriver.com wrote:
> > > From: Kai Kang
> > >
> > > There is a multilib install file conflict of nss:
> > > > file /etc/pki/nssdb/key4.db conflicts be
On 2018年09月29日 20:44, Richard Purdie wrote:
On Sat, 2018-09-29 at 13:43 +0800, kai.k...@windriver.com wrote:
From: Kai Kang
There is a multilib install file conflict of nss:
file /etc/pki/nssdb/key4.db conflicts between attempted installs of
lib32-nss-3.38-r0.corei7_32 and nss-3.38-r0.corei7_
Current Dev Position: YP 2.6 M4.
Next Deadline: YP 2.6 M4 Build Target is Oct. 1, 2018
SWAT Team Rotation:
* SWAT lead is currently: Armin
* SWAT team rotation: Armin -> Paul on Oct. 5, 2018
* SWAT team rotation: Paul -> Ross on Oct. 12, 2018
* https://wiki.yoctoproject.org/wiki/Y
On 02.10.2018 10:46, Stefan Agner wrote:
> On 26.09.2018 11:34, Stefan Agner wrote:
>> Hi,
>>
>> On 12.09.2018 00:49, Stefan Agner wrote:
>
>> We discussed the issue at Linaro Connect a bit.
>>
>> To recap, we do build in two steps:
>>
>> 1. bitbake full-container-image
>> 2. bitbake -c populate_s
*ping*
//Peter
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org core-boun...@lists.openembedded.org> On Behalf Of Peter Kjellerstedt
> Sent: den 25 september 2018 11:17
> To: Richard Purdie ; openembedded-
> c...@lists.openembedded.org
> Subject: Re: [OE-core
As part of the solution to replace Testopia to store testresult,
OEQA testimage need to output testresult into json files, where
these json testresult files will be stored into git repository
by the future test-case-management tools.
By default, testimage will write json testresult, to disable
thi
As part of the solution to replace Testopia to store testresult,
OEQA selftest need to output testresult into json files, where
these json testresult files will be stored into git repository
by the future test-case-management tools.
By default, oe-selftest will write json testresult into files.
To
As part of the solution to replace Testopia to store testresult,
OEQA sdk and sdkext need to output testresult into json files, where
these json testresult files will be stored into git repository
by the future test-case-management tools.
By default, sdk and sdkext will write json testresult, to d
As part of the solution to replace Testopia to store testresult,
OEQA need to output testresult into json files, where these json
testresult files will be stored in git repository by the future
test-case-management tools.
Both the testresult (eg. PASSED, FAILED, ERROR) and the test log
(eg. messa
On 26.09.2018 11:34, Stefan Agner wrote:
> Hi,
>
> On 12.09.2018 00:49, Stefan Agner wrote:
> We discussed the issue at Linaro Connect a bit.
>
> To recap, we do build in two steps:
>
> 1. bitbake full-container-image
> 2. bitbake -c populate_sdk full-container-image
>
> The issue always happe
Hello Richard,
Would assure you if it generated the test data on image creation *and*
on test task?
If not please describe more or less how I could collect which
variables write_image_test_data depends upon. Just a high level
description would do.
I have really been in a good spirit to get this t
Hi all,
I would like to ask you a question about including debug packages in
rootfs-debug. Is there any official way how to install debug package of
static library instead of explicitly adding it into IMAGE_INSTALL?
One way is what I have found is:
FILES_${PN} = ""
ALLOW_EMPTY_${PN} = "1"
After
39 matches
Mail list logo
