While working with ostree disk generation in conjunction with wic, I
found a problem with pseudo where it tried to resolve a symlink when
it shouldn't, based on openat() flags. I narrowed down the problem to
a simple c program to reproduce the issue:
int main()
{
/* Tested with: gcc -Wall -o
> > Wouldn't it be a bit overkill to add a new class just to handle SRC_URI? I
> > would think it would just be a little extra code inside
> write_latest_srcrev.
>
> Ordinarily I'd say yes. But RP had concerns that these changes add up and
> unless everyone wants them it could prove to be a
While this is a real problem. We need to put this patch on hold.
It seems to have caused really odd problems with the oe link management that
were not there previously, such as:
WARNING: pinentry-1.1.0-r0 do_package_qa: QA Issue: pinentry: /usr/bin/pinentry
is owned by uid 5002, which is
Signed-off-by: Oleksandr Kravchuk
---
.../python/{python3-git_2.1.12.bb => python3-git_2.1.13.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-devtools/python/{python3-git_2.1.12.bb =>
python3-git_2.1.13.bb} (88%)
diff --git
On 8/1/19 2:01 PM, Nicolas Dechesne wrote:
hi,
I am trying to make up some sense with the bitbake output at the end
of my build. I have enabled buildstats and buildstats-summary.
What do all these numbers mean? They don't quite sum up..
Sstate summary: Wanted 15 Found 9 Missed 12 Current 125
On 8/1/19 1:03 PM, chris.lapla...@agilent.com wrote:
>> I've had some thoughts of capturing that same information, as well as
>> automatically generating a changelog (from short-commit entries) from the
>> last
>> build to the current one use standard git commands... but I've never had
>> time
Looks like the checksum license changed between the prior commit and now. So
I'll send a v2, because we don't want to break the master branch of oe-core.
Cheers,
Jason.
On 8/1/19 12:55 PM, Jason Wessel wrote:
While working with ostree disk generation in conjunction with wic, I
found a
All local patches are now upstream so they have been dropped.
Other upstream commits make ptest-runner build using: clang -Weverything
$ git log --oneline b73bd54..7015e91
7015e91 (HEAD -> oe-core-master, tag: v2.3.2, origin/master, origin/HEAD,
master) Fix additional warnings when using clang
On 01/08/2019 02:24, Mittal, Anuj wrote:
An earlier patch for the same upgrade didn't make it in and probably
fell through the cracks. Can we pick those upgrades?
https://patchwork.openembedded.org/series/18658/
Already in MUT, I'll prod RP.
Ross
On Thu, 2019-08-01 at 10:03 +0100, Ross Burton wrote:
> On 01/08/2019 02:24, Mittal, Anuj wrote:
> > An earlier patch for the same upgrade didn't make it in and
> > probably
> > fell through the cracks. Can we pick those upgrades?
> >
> > https://patchwork.openembedded.org/series/18658/
>
>
On 7/31/19 10:37 PM, Adrian Bunk wrote:
On Wed, Jul 31, 2019 at 10:19:24PM -0700, Khem Raj wrote:
I don’t remember if mips disable reason was same as aarch64 I hope it was
not a runtime failure can you dig a bit
Author: Khem Raj
Date: Mon Aug 8 15:51:00 2016 -0700
webkitgtk: Disable
On Thu, 1 Aug 2019 16:37:26 -0500
Jason Wessel wrote:
> It seems to have caused really odd problems with the oe link
> management that were not there previously, such as:
>
>
> WARNING: pinentry-1.1.0-r0 do_package_qa: QA Issue:
> pinentry: /usr/bin/pinentry is owned by uid 5002, which is the
From: Changqing Li
when runqemu with slirp option on same host with different
users, it will report PermissionError: [Errno 13] Permission
denied: '/tmp/qemu-port-locks/.lock'
and during handle this exception, another exception happened since
key not exist. Fix by check if key exist first
instead of posting whole shortlog to commit perhaps pointing to ko git
log is going to save us some bits in git history
something like
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=linux-4.19.y=range=5dd6139a0aa2..7250956f6eaf
On Thu, Aug 1, 2019 at 7:33 PM wrote:
>
>
From: Bruce Ashfield
Integrating the korg -stable commits that comprise the following
changes:
7250956f6eaf Linux 4.19.61
025eb12bb4b0 dm bufio: fix deadlock with loop device
404f59e265ac dt-bindings: allow up to four clocks for orion-mdio
03e6a668ea1f net: mvmdio: allow up to four
From: Bruce Ashfield
Signed-off-by: Bruce Ashfield
---
meta/recipes-kernel/linux/linux-yocto-dev.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb
b/meta/recipes-kernel/linux/linux-yocto-dev.bb
index 8c83620d39..96117ccf3f
-libnss-nis/0001-nis-hosts-Remove-use-of-RES_USE_INET6.patch
Removed since this is included in 3.1.
Signed-off-by: Zang Ruochen
---
meta/recipes-extended/libnss-nis/libnss-nis.bb | 5 +-
...001-nis-hosts-Remove-use-of-RES_USE_INET6.patch | 162 -
2 files changed, 2
On 01/08/2019 12:37, Richard Purdie wrote:
On Thu, 2019-08-01 at 10:22 +0100, Richard Purdie wrote:
On Thu, 2019-08-01 at 10:03 +0100, Ross Burton wrote:
On 01/08/2019 02:24, Mittal, Anuj wrote:
An earlier patch for the same upgrade didn't make it in and
probably
fell through the cracks. Can
On Thu, Aug 1, 2019 at 4:17 AM Mike Looijmans wrote:
>
> On 31-07-19 15:29, Ross Burton wrote:
> > On 31/07/2019 14:22, Mike Looijmans wrote:
> >> Well, that's at least good to know.
> >>
> >> I'm on the "thud" branch currently, so I hope this isn't something that got
> >> fixed only recently.
>
Alexander
Either this or the next patch in this series seems to be causing
https://errors.yoctoproject.org/Errors/Details/256700/
On Tue, Jul 30, 2019 at 8:55 AM Alexander Kanavin
wrote:
>
> Drop backports.
>
> Rebase other patches.
>
> Signed-off-by: Alexander Kanavin
> ---
>
On 2019/08/01 18:17, Seebs wrote:
> > + rc = real___fxstatat64(_STAT_VER, dirfd, path, ,
> > AT_SYMLINK_NOFOLLOW);
>
> We should probably be using flags here, not AT_SYMLINK_NOFOLLOW.
> Or possibly (flags & AT_SYMLINK_NOFOLLOW). Otherwise, we'll get the wrong
> results if called with flags
From: Max Kellermann
Signed-off-by: Max Kellermann
---
ports/linux/guts/faccessat.c | 33 +
ports/linux/wrapfuncs.in | 1 +
2 files changed, 34 insertions(+)
create mode 100644 ports/linux/guts/faccessat.c
diff --git a/ports/linux/guts/faccessat.c
On Thu, 1 Aug 2019 18:02:06 +0200
Max Kellermann wrote:
> + * wrap_access(int dirfd, const char *path, int mode, int flags) {
This should probably say "faccessat". I know it's just a comment, but
I try to be consistent about these.
> + rc = real___fxstatat64(_STAT_VER, dirfd, path, ,
>
== Series Details ==
Series: ports/linux: wrap faccessat() (rev2)
Revision: 2
URL : https://patchwork.openembedded.org/series/19012/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed
== Series Details ==
Series: ports/linux: wrap faccessat()
Revision: 1
URL : https://patchwork.openembedded.org/series/19012/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the
Hello all,
Most of my team's closed source recipes use something like the following:
SRC_URI = "git://git@host/path;protocol=ssh;branch=${BRANCH}"
SRCREV = "${AUTOREV}"
BRANCH ??= "master"
(BRANCH is just a convention we use to make the SRC_URI branch easy to
override.)
This makes nightly
Apologies, but I think you should drop the practice of using AUTOREV. This
completely destroys reproducibility of builds, and makes them susceptible
to global breakage when someone pushes a broken commit into one of the
component repositories.
Yes, bumping SRCREV is annoying, but a) it can be
We’re well aware of the limitations and possibility of failed builds, as I said
we hardcode revisions using SRCREV overrides when necessary. It’s been working
well for us so far. So, respectfully, I think that’s not relevant to the
discussion.
Chris
From: Alexander Kanavin
Sent: Thursday,
On 8/1/19 11:51 AM, chris.laplante--- via bitbake-devel wrote:
> Hello all,
>
>
>
> Most of my team’s closed source recipes use something like the following:
>
>
>
> SRC_URI = "git://git@host/path;protocol=ssh;branch=${BRANCH}"
>
> SRCREV = “${AUTOREV}”
>
> BRANCH ??= “master”
>
>
>
Signed-off-by: Adrian Bunk
---
meta/recipes-bsp/grub/grub2.inc | 2 +-
meta/recipes-devtools/gdb/gdb-8.3.inc | 2 +-
meta/recipes-support/libmpc/libmpc_1.1.0.bb | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-bsp/grub/grub2.inc
On 31-07-19 15:29, Ross Burton wrote:
> On 31/07/2019 14:22, Mike Looijmans wrote:
>> Well, that's at least good to know.
>>
>> I'm on the "thud" branch currently, so I hope this isn't something that got
>> fixed only recently.
>>
>> I'll try some simple images first. I gather there's no
On Thu, 2019-08-01 at 10:22 +0100, Richard Purdie wrote:
> On Thu, 2019-08-01 at 10:03 +0100, Ross Burton wrote:
> > On 01/08/2019 02:24, Mittal, Anuj wrote:
> > > An earlier patch for the same upgrade didn't make it in and
> > > probably
> > > fell through the cracks. Can we pick those upgrades?
From: Max Kellermann
Signed-off-by: Max Kellermann
---
ports/linux/guts/faccessat.c | 33 +
ports/linux/wrapfuncs.in | 1 +
2 files changed, 34 insertions(+)
create mode 100644 ports/linux/guts/faccessat.c
diff --git a/ports/linux/guts/faccessat.c
Some people mistakenly use DEPENDS_${PN} and wonder why the dependencies don't
work. Check for this and tell the user to use DEPENDS.
Signed-off-by: Ross Burton
---
meta/classes/insane.bbclass | 5 +
1 file changed, 5 insertions(+)
diff --git a/meta/classes/insane.bbclass
== Series Details ==
Series: Use GNU_MIRROR in more recipes
Revision: 1
URL : https://patchwork.openembedded.org/series/19014/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the
While working with ostree disk generation in conjunction with wic, I
found a problem with pseudo where it tried to resolve a symlink when
it shouldn't, based on openat() flags. I narrowed down the problem to
a simple c program to reproduce the issue:
int main()
{
/* Tested with: gcc -Wall -o
> I've had some thoughts of capturing that same information, as well as
> automatically generating a changelog (from short-commit entries) from the last
> build to the current one use standard git commands... but I've never had time
> to
> implement anything.
>
> When I talked with RP about this
On Thu, 1 Aug 2019 10:55:45 -0700
Jason Wessel wrote:
> Many thanks to Peter Seebach for fixing the problem in the pseudo code
> to use the same logic which was already there for the
> AT_SYMLINK_NOFOLLOW.
Special credit goes to Past Seebs, who thoughtfully made the parser
for wrapfuncs
hi,
I am trying to make up some sense with the bitbake output at the end
of my build. I have enabled buildstats and buildstats-summary.
What do all these numbers mean? They don't quite sum up..
Sstate summary: Wanted 15 Found 9 Missed 12 Current 125 (60% match,
95% complete)
NOTE: Executing
39 matches
Mail list logo
