Apparently there are recipes in the wild which generate files with
filenames containing '$' characters - which cause errors during
packaging.
Instead of adding another special case to escape '$' characters when
constructing the command passed to oe.utils.getstatusoutput(), switch
to using single q
Although get_filesystem_id() is a private API and never gets passed
a path containing spaces or other special characters, etc, quote the
path anyway for consistency.
Signed-off-by: Andre McCurdy
---
meta/classes/sanity.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/m
On Fri, 23 Mar 2018 18:43:12 -0700
Andre McCurdy wrote:
> Since glibc doesn't provide a wrapper for renameat2, making the
> syscall via the libc syscall() API is exactly what coreutils (actually
> gnulib) should be doing. There would certainly be grounds to complain
> if user space code were maki
On Fri, Mar 23, 2018 at 6:17 PM, Seebs wrote:
> On Fri, 23 Mar 2018 18:10:21 -0700
> Andre McCurdy wrote:
>
>> The syscall wrapper in musl handles 6 additional arguments -
>> unconditionally. Based on that you might not need to interpret
>> anything - just extract 6 arguments and pass them on?
>>
On Fri, 23 Mar 2018 18:10:21 -0700
Andre McCurdy wrote:
> The syscall wrapper in musl handles 6 additional arguments -
> unconditionally. Based on that you might not need to interpret
> anything - just extract 6 arguments and pass them on?
>
> long syscall(long n, ...)
> {
> va_list ap;
>
On Fri, Mar 23, 2018 at 5:36 PM, Seebs wrote:
> On Fri, 23 Mar 2018 17:33:28 -0700
> Andre McCurdy wrote:
>
>> Interposing the libc syscall wrapper doesn't seem to scary if you can
>> transparently pass on everything apart from syscall(SYS_renameat2,
>> ...) ?
>
> I don't think I can in the gener
On Fri, 23 Mar 2018 17:33:28 -0700
Andre McCurdy wrote:
> Interposing the libc syscall wrapper doesn't seem to scary if you can
> transparently pass on everything apart from syscall(SYS_renameat2,
> ...) ?
I don't think I can in the general case; I don't know how many
arguments every possible sy
On Fri, Mar 23, 2018 at 4:56 PM, Seebs wrote:
> On Fri, 23 Mar 2018 23:47:30 +
> Richard Purdie wrote:
>> On Fri, 2018-03-23 at 11:49 -0500, Seebs wrote:
>> > On Fri, 23 Mar 2018 16:30:55 +
>> > "Burton, Ross" wrote:
>> > > Because in GNU's infinite wisdom they're using renameat2() to do
Seebs writes:
>> > I... am really unsure whether it's possible to catch that, because
>> > I really, really, don't want to try to intercept raw syscall()
>> > calls. I don't think that ends well.
>
> Potentially. We rely pretty heavily on the assumption that an *actual*
> syscall can go through.
On Fri, 23 Mar 2018 23:47:30 +
Richard Purdie wrote:
> On Fri, 2018-03-23 at 11:49 -0500, Seebs wrote:
> > On Fri, 23 Mar 2018 16:30:55 +
> > "Burton, Ross" wrote:
> >
> > >
> > > Because in GNU's infinite wisdom they're using renameat2() to do
> > > atomic renames in the mv command, a
On Fri, 2018-03-23 at 11:49 -0500, Seebs wrote:
> On Fri, 23 Mar 2018 16:30:55 +
> "Burton, Ross" wrote:
>
> >
> > Because in GNU's infinite wisdom they're using renameat2() to do
> > atomic renames in the mv command, and as renameat2 isn't in the
> > headers for F27 it just does a syscall d
Yes, I saw it when it merged few days ago. Thanks!
On Fri, Mar 23, 2018 at 01:57:57PM -0700, akuster808 wrote:
>
>
> On 03/15/2018 10:49 AM, Denys Dmytriyenko wrote:
> > Ping. Any ETA for when it will be merged to morty?
>
> Not sure if I answered this. Its now in morty
>
> http://git.yoctopr
On 03/15/2018 10:49 AM, Denys Dmytriyenko wrote:
> Ping. Any ETA for when it will be merged to morty?
Not sure if I answered this. Its now in morty
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=morty&id=34b26ec18450a3bc72f7b8a0f2df0bfaae1140dd
- armin
>
>
> On Mon, Mar 05, 2018 at 0
Signed-off-by: Khem Raj
---
Changes since v1:
- Add Sign-off field
...ncpy-with-memccpy-to-fix-Wstringop-trunca.patch | 40 ++
meta/recipes-core/glibc/glibc_2.27.bb | 1 +
2 files changed, 41 insertions(+)
create mode 100644
meta/recipes-core/glibc/glibc/0029-
All,
I’m working on a bundled package from NXP that’s based on Yocto Krogroth (so
2015 ish). But now I need to update openssl from 1.0.2d to 1.0.2n to fix
multiple CVE vulnerabilities. However, this is proving to be quite difficult.
I’ve been able to upgrade curl, expat, python, etc. by add
On Fri, 23 Mar 2018 16:56:16 +
"Burton, Ross" wrote:
> On 23 March 2018 at 16:49, Seebs wrote:
> > On Fri, 23 Mar 2018 16:30:55 +
> > "Burton, Ross" wrote:
> >
> >> Because in GNU's infinite wisdom they're using renameat2() to do
> >> atomic renames in the mv command, and as renameat2 i
On 23 March 2018 at 16:49, Seebs wrote:
> On Fri, 23 Mar 2018 16:30:55 +
> "Burton, Ross" wrote:
>
>> Because in GNU's infinite wisdom they're using renameat2() to do
>> atomic renames in the mv command, and as renameat2 isn't in the
>> headers for F27 it just does a syscall directly. This is
On Fri, 23 Mar 2018 16:30:55 +
"Burton, Ross" wrote:
> Because in GNU's infinite wisdom they're using renameat2() to do
> atomic renames in the mv command, and as renameat2 isn't in the
> headers for F27 it just does a syscall directly. This is in upstream
> coreutils so once they make a rele
On 23 March 2018 at 16:28, Seebs wrote:
> On Fri, 23 Mar 2018 17:10:35 +0100
> Enrico Scholz wrote:
>
>> I think, 'mv' is the culprit. It calls 'renameat2()' directly over
>> 'syscall()':
>>
>> | $ ltrace mv foo bar
>> | ...
>> | syscall(316, 0xff9c, 0x7fff1564a341,
>> 0xff9c)
On Fri, 23 Mar 2018 17:10:35 +0100
Enrico Scholz wrote:
> I think, 'mv' is the culprit. It calls 'renameat2()' directly over
> 'syscall()':
>
> | $ ltrace mv foo bar
> | ...
> | syscall(316, 0xff9c, 0x7fff1564a341,
> 0xff9c)= 0
>
>
> Perhaps
On 23 March 2018 at 16:10, Enrico Scholz
wrote:
> "Burton, Ross" writes:
>
>>> do_install() {
>>> install -D -p -m 0644 bar ${D}/bin/bar
>>> install -d -m 0755 ${D}/usr/bin
>>> mv ${D}/bin/bar ${D}/usr/bin/bar
>>> ln -s /usr/bin/bar ${D}/bin/bar
>>> }
>>>
>>> FILES
"Burton, Ross" writes:
>> do_install() {
>> install -D -p -m 0644 bar ${D}/bin/bar
>> install -d -m 0755 ${D}/usr/bin
>> mv ${D}/bin/bar ${D}/usr/bin/bar
>> ln -s /usr/bin/bar ${D}/bin/bar
>> }
>>
>> FILES_${PN} = "/bin/* /usr/bin/*"
>> ---
>>
>> WARNING: foo-1.0-r
Ah, I just read this other message of yours, which includes the fact
that you're on F27.
Yes, something in F27 has just broken pseudo quite dramatically. No
idea what, so far.
Ross
On 23 March 2018 at 15:33, Enrico Scholz
wrote:
> Hello,
>
> in some packages (e.g. ncurses or glibc) I get packa
> Enrico Scholz
>
> writes:
>
>> in some packages (e.g. ncurses or glibc) I get package-qa warnings due
>> to host user contamination; e.g.
>
> can be reproduced by
>
> ---
> LICENSE = "closed"
>
> do_compile() {
> echo foo > bar
> }
>
> do_install() {
> install -D -p -m 0644 bar $
Enrico Scholz
writes:
> in some packages (e.g. ncurses or glibc) I get package-qa warnings due
> to host user contamination; e.g.
can be reproduced by
---
LICENSE = "closed"
do_compile() {
echo foo > bar
}
do_install() {
install -D -p -m 0644 bar ${D}/bin/bar
install -
That would be the ideal.
Ross
On 23 March 2018 at 14:56, Alexander Kanavin
wrote:
> On 03/23/2018 04:31 PM, Burton, Ross wrote:
>>
>> So many questions.
>>
>> What did we ship? Why doesn't it exist upstream anymore?
>>
>> Shipping a fork in a personal repo sounds like a good solution for the
>>
Hello,
in some packages (e.g. ncurses or glibc) I get package-qa warnings due
to host user contamination; e.g.
| WARNING: ncurses-6.0+20170715-r0 do_package_qa: QA Issue: ncurses:
/ncurses-terminfo-base/etc/terminfo/a/ansi is owned by uid 505, which is the
same as the user running bitbake. This
This item doesn't appear to have a follow-up.
On Wed, Oct 4, 2017 at 11:10 AM, Burton, Ross wrote:
> On 3 October 2017 at 19:17, Peter Kjellerstedt <
> peter.kjellerst...@axis.com> wrote:
>
>> > + # Take shared lock since we're only reading, not writing
>> > lf = bb.utils.lockfile(bb.d
On 03/23/2018 04:31 PM, Burton, Ross wrote:
So many questions.
What did we ship? Why doesn't it exist upstream anymore?
Shipping a fork in a personal repo sounds like a good solution for the
stable branches following the principle of least surprise: they're
shipping what they always did. For
Fix non-void function 'fix_options' should return a value.
Add function prototype to tcpd.c and miscd.c.
Signed-off-by: Oleksiy Obitotskyy
---
v2 - add function prototypes
.../0001-Fix-build-with-clang.patch| 65 ++
.../tcp-wrappers/tcp-wrappers_7.6.bb
So many questions.
What did we ship? Why doesn't it exist upstream anymore?
Shipping a fork in a personal repo sounds like a good solution for the
stable branches following the principle of least surprise: they're
shipping what they always did. For master/2.5 though, I'm not happy
about it (but
On 03/22/2018 10:25 PM, Khem Raj wrote:
> On Thu, Mar 22, 2018 at 10:04 PM, Armin Kuster wrote:
>> From: Armin Kuster
>>
>> ERROR: distcc-3.2-r0 do_fetch: Fetcher failure: Unable to find revision
>> d8b18df3e9dcbe4f092bed565835d3975e99432c in branch 3.2 even from upstream
>> ERROR: distcc-3.2-
On 03/22/2018 10:25 PM, Khem Raj wrote:
> On Thu, Mar 22, 2018 at 10:04 PM, Armin Kuster wrote:
>> From: Armin Kuster
>>
>> ERROR: distcc-3.2-r0 do_fetch: Fetcher failure: Unable to find revision
>> d8b18df3e9dcbe4f092bed565835d3975e99432c in branch 3.2 even from upstream
>> ERROR: distcc-3.2-
== Series Details ==
Series: "elfutils: Fix gcc compile time..." and 2 more
Revision: 1
URL : https://patchwork.openembedded.org/series/11549/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been
Allow devtool to organize the SRC_URI
Signed-off-by: Khem Raj
---
meta/recipes-devtools/elfutils/elfutils_0.170.bb | 40 +++---
...-packed-structs-follow-the-gcc-memory-lay.patch | 34 +
...de-alternatives-for-glibc-assumptions-hel.patch | 144 ++---
3 files changed, 124
Fies security warnings
| sign.c:86:31: error: 'sprintf' may write a terminating nul past the end of
the destination [-Werror=format-overflow=]
| sprintf(fullfn, "%s/%s", tree, tempfn);
Signed-off-by: Khem Raj
---
...1437734-Use-snprintf-in-sign.c-r-ttaubert.patch | 119
Signed-off-by: Khem Raj
---
...ncpy-with-memccpy-to-fix-Wstringop-trunca.patch | 39 ++
meta/recipes-core/glibc/glibc_2.27.bb | 1 +
2 files changed, 40 insertions(+)
create mode 100644
meta/recipes-core/glibc/glibc/0029-Replace-strncpy-with-memccpy-to-fix-Wstr
Hi Victor,
Sorry for the delay in these, it may not have been obvious from the
list but M3 has been a struggle and then it was ELC. I'll put these
on my list to review today.
Ross
On 22 March 2018 at 17:53, Victor Kamensky wrote:
> Hi Folks,
>
> Based on my conversation with Richard during con
On Fri, Mar 23, 2018 at 4:16 AM, Oleksiy Obitotskyy (cisco)
wrote:
> Hello,
>
> I would like to clarify your question.
> Function fix_options has no prototype into tcpd.c and miscd.c and generate
> warnings
> 'warning: implicit declaration of function' but links fine.
> So should I add prototype f
Use ext4 filesystem instead of ext3 when using the live image to install
on target. wic defaults to ext4 as well.
Signed-off-by: Anuj Mittal
---
meta/recipes-core/initrdscripts/files/init-install-efi.sh | 6 +++---
meta/recipes-core/initrdscripts/files/init-install.sh | 6 +++---
2 files cha
Hello,
I would like to clarify your question.
Function fix_options has no prototype into tcpd.c and miscd.c and
generate warnings
'warning: implicit declaration of function' but links fine.
So should I add prototype for fix_options or leave it as is?
Regards,
Oleksiy
On 23.03.18 07:21, Khem R
* Fix RDEPENDS
Upstream release notes:
2.25 2018-03-18 16:18:24+13:00 Pacific/Auckland
- disable entity expansion when using XML::Parser, for more secure default
behaviour (patch from Ray Morris)
- call to XML::Parser constructor is now in its own method to ease overriding
License-Up
== Series Details ==
Series: "libxml-simple-perl: upgrade 2" and 1 more
Revision: 1
URL : https://patchwork.openembedded.org/series/11543/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been
* Fix RDEPENDS
* Upstream v1.12_9 is a development version, not a stable release
* Add UPSTREAM_CHECK_REGEX skip development releases
* Drop anonymous python function to "fix" version, which breaks
auto-upgrade-helper (AUH)
* Use LICENSE file for checksum rather than ephemeral META.yml
* License
* Fix RDEPENDS
Upstream release notes:
2.25 2018-03-18 16:18:24+13:00 Pacific/Auckland
- disable entity expansion when using XML::Parser, for more secure default
behaviour (patch from Ray Morris)
- call to XML::Parser constructor is now in its own method to ease overriding
License-Up
when i open a particular recipe on layer.openembeded site it showcases
something called dependencies does it mean that those list under the
dependencies should be included in CORE_IMAGE_EXTRA_INSTALL??
Thanks
--
___
Openembedded-core mailing list
Openem
46 matches
Mail list logo
