So, here is an update for those not following on IRC:
[Re: [OE-core] Summary of the remaining 6.5 kernel serial issue (and 6.5
summary)] On 11/10/2023 (Wed 00:50) Paul Gortmaker wrote:
[snip details of getting RP's chunk of AB python working as a 1% reproducer]
> Next steps:
>
[Re: [OE-core] Summary of the remaining 6.5 kernel serial issue (and 6.5
summary)] On 10/10/2023 (Tue 21:53) Richard Purdie via lists.openembedded.org
wrote:
> On Tue, 2023-10-10 at 21:37 +0100, Richard Purdie via
> lists.openembedded.org wrote:
> > I've been asked how to reproduce this setup mo
[Re: [OE-core][mickledore 00/18] Patch review] On 17/08/2023 (Thu 23:17) Paul
Gortmaker via lists.openembedded.org wrote:
> [Re: [OE-core][mickledore 00/18] Patch review] On 16/08/2023 (Wed 07:50)
> Steve Sakoman via lists.openembedded.org wrote:
>
> > On Tue, Aug 15, 2023 at
[Re: [OE-core] Dilemma on changes - merge or not to merge (e.g. 6.4)] On
16/08/2023 (Wed 09:55) Rasmus Villemoes wrote:
> 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
> >
[Re: [OE-core][mickledore 00/18] Patch review] On 16/08/2023 (Wed 07:50) Steve
Sakoman via lists.openembedded.org wrote:
> On Tue, Aug 15, 2023 at 6:24???AM Steve Sakoman via
> lists.openembedded.org
> wrote:
> >
> > Please review this set of changes for mickledore and have comments back by
> >
[Dilemma on changes - merge or not to merge (e.g. 6.4)] On 14/08/2023 (Mon
10:54) Richard Purdie wrote:
> I'm becoming a little weary/wary of some of the changes that are coming
> in. The challenge is that once they merge, issues become the problem of
> a very small number of people.
>
> My curr
[Re: [PATCH 1/2] qemux86/conf: TEST ONLY. Drop smp boot] On 09/06/2023 (Fri
10:08) Bruce Ashfield wrote:
> On Fri, Jun 9, 2023 at 2:06???AM Richard Purdie
> wrote:
> >
[...]
> > FWIW, this patch didn't change much. With it applied we still see:
>
>
> ok. so at least we can rule out it being
Somehow these two got left behind and hence on older hosts that
are using buildtools for a newer python - they will still fail.
Signed-off-by: Paul Gortmaker
diff --git a/scripts/buildstats-diff b/scripts/buildstats-diff
index 2f6498ab6743..c9aa76a8fafc 100755
--- a/scripts/buildstats-diff
[[OE-core] [PATCH] kernel: improve initramfs bundle processing time] On
14/04/2023 (Fri 15:29) Bruce Ashfield via lists.openembedded.org wrote:
> From: Bruce Ashfield
>
> This is a partial fix for bugzilla 15059
> [https://bugzilla.yoctoproject.org/show_bug.cgi?id=15059]
>
> It has been noted
[Re: [OE-core] mesa-native fails on master] On 04/04/2023 (Tue 02:39) Chen Qi
via lists.openembedded.org wrote:
> I just met the same issue. My host is ubuntu18, gcc version is 7.5.0.
Note that ubuntu-18.04 is End-of-Life in another three weeks (unless you
buy additional support) - in case peopl
7;s suggestion and mine.
As such we now also can store commit logs and use send-email with our user
specific settings, instead of "root", so in additon to fixing basic
commands like "git branch" it should also increase general usefulness.
Cc: Richard Purdie
Signed-off-by: P
This false positive keeps showing up in our testing but the fix isn't
yet a part of a tagged release, and it is probably too late for doing
an uprev for the fall release anyway.
Signed-off-by: Paul Gortmaker
diff --git
a/meta/recipes-extended/ltp/ltp/0001-syscalls-ioctl_ns05.c-ioctl_ns06.
[Re: [swat] ltp failures on autobuilder] On 11/06/2021 (Fri 14:19) Richard
Purdie wrote:
> On Fri, 2021-06-11 at 12:36 +0100, Richard Purdie via lists.yoctoproject.org
> wrote:
> > as a .cfg to the kernel and that still reproduced the crash. However:
> >
> > CONFIG_DEBUG_KERNEL=y
> > CONFIG_CGR
[Re: [PATCH] systemd: dont spew hidepid mount errors for kernels < v5.8] On
15/01/2021 (Fri 09:57) Luca Boccassi wrote:
> On Fri, 2021-01-15 at 08:37 +, Richard Purdie wrote:
> > On Fri, 2021-01-15 at 00:26 -0500, Paul Gortmaker wrote:
> > > Recent systemd starte
00..65e7eca32d05
--- /dev/null
+++
b/meta/recipes-core/systemd/systemd/0027-proc-dont-trigger-mount-error-with-invalid-options-o.patch
@@ -0,0 +1,126 @@
+From 297aba739cd689e4dc9f43bb1422ec88d481099a Mon Sep 17 00:00:00 2001
+From: Paul Gortmaker
+Date: Wed, 13 Jan 2021 21:09:33 +
+Su
; with a single dash
After:
SDK_VENDOR should be of the form '-foosdk' with a single dash; found
'-overc-sdk'
Cc: Ross Burton
Signed-off-by: Paul Gortmaker
diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index 8e814a48..c823b49c03b0 100644
---
> > > TX-DRP
> > > > TX-OVR Flg
> > > > -eth0 1500 0 7736406 0 2016
> > > > 0 5289455 0 0 0 BMRU
> > > > -lo65536 018 0 0
> > > > 018000 LRU
> &g
commit show the same
dates and commit log and point at 5.30, so hopefully this is
the right thing to do. A git diff of the two seems to only show
a blanket uprev of CVS tags and deletion of a couple autogen'd
files, and no real source changes.
Cc: Christos Zoulas
Signed-off-by: Paul Gortmaker
ps=False"] if
self.d.getVar('NO_RECOMMENDATIONS') == 1 else []) +
Exception: NameError: name 'package_exlcude' is not defined
ERROR: cube-builder-initramfs-1.0-r0 do_rootfs: Function failed: do_rootfs
-----
Cc: Alexander Kanavin
Signed-off-by
To fix:
file /usr/share/man/man1/dnsdomainname.1 conflicts between attempted installs
of inetutils-doc-1.9.4-r0.core2_64 and net-tools-doc-1.60+26-r0.core2_64
Signed-off-by: Paul Gortmaker
---
meta/recipes-extended/net-tools/net-tools_1.60-26.bb | 3 ++-
1 file changed, 2 insertions(+), 1
To fix:
file /usr/share/man/man1/which.1 conflicts between attempted installs
of debianutils-doc-4.8.1-r0.core2_64 and which-doc-2.21-r3.core2_64
Signed-off-by: Paul Gortmaker
---
meta/recipes-extended/which/which_2.21.bb | 3 +++
meta/recipes-support/debianutils
To fix:
file /usr/share/man/man8/syslogd.8 conflicts between attempted installs
of inetutils-doc-1.9.4-r0.core2_64 and sysklogd-doc-1.5.1-r0.core2_64
Signed-off-by: Paul Gortmaker
---
meta/recipes-extended/sysklogd/sysklogd.inc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta
e the default.
Signed-off-by: Paul Gortmaker
---
meta/recipes-devtools/gdb/gdb-common.inc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/gdb/gdb-common.inc
b/meta/recipes-devtools/gdb/gdb-common.inc
index 5b8087c3ba8f..239b37586b77 100644
--- a/meta/re
-r0.core2_64
Signed-off-by: Paul Gortmaker
---
meta/recipes-core/util-linux/util-linux.inc | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-core/util-linux/util-linux.inc
b/meta/recipes-core/util-linux/util-linux.inc
index 821f7c8751e9..708c041d20e7 100644
--- a
.core2_64
file /usr/share/man/man1/logger.1 conflicts between attempted installs of
util-linux-doc-2.29.1-r0.core2_64 and inetutils-doc-1.9.4-r0.core2_64
Paul Gortmaker (5):
gdb: don't bundle bfd.info -- leave that to binutils.
which: fix it so the manpage will respect alternatives
After updating this morning (everything on master, re-using the existing
build dir that was built OK within the last 48h) I saw this:
ERROR: pseudo-native-1.8.1-r0 do_populate_sysroot: pseudo-native: chrpath
command failed with exit code 7:
b'/home/paul/poky/build/tmp/work/x86_64-linux/pseudo-nat
bled so undo the always parsing
> flag in this case.
>
> Signed-off-by: Richard Purdie
Applied the revert and this take 2, and I see:
7: linux-yocto-dev-4.6-rc++gitAUTOINC+81548cf96c_673790d078-r0 do_unpack (pid
29471)
It would have blown up in fetch with take 1, so
Tested-by: Paul
ange here is just temporary and the coreutils team
will put the default back to the old way it was based on feedback
similar to what is recorded in the above Debian bug.
Signed-off-by: Paul Gortmaker
---
[v2: reword commit to reflect general hope that the change in OE will
only be nee
[Re: [OE-core] [PATCH] coreutils: revert upstream commit causing havoc with ls
output] On 21/05/2016 (Sat 12:18) Olof Johansson wrote:
> On 16-05-20 20:02 -0400, Paul Gortmaker wrote:
> > Several large distros are voting with their feet and actively
> > reverting the change, as
r feet and actively
reverting the change, as per what can be seen above for Debian.
Here we do the same; I've marked the patch as upstream inappropriate
since it doesn't appear that the coreutils folks are going to change
the default back to the old way based on what we do here.
Signed-o
[Re: runtime regression with "x86/mm/pat: Emulate PAT when it is disabled"] On
04/03/2016 (Fri 15:12) Toshi Kani wrote:
> On Fri, 2016-03-04 at 13:37 -0500, Paul Gortmaker wrote:
> > [Re: runtime regression with "x86/mm/pat: Emulate PAT when it is
> > disabled&quo
[Re: runtime regression with "x86/mm/pat: Emulate PAT when it is disabled"] On
03/03/2016 (Thu 22:02) Toshi Kani wrote:
> On Thu, 2016-03-03 at 15:59 -0500, Paul Gortmaker wrote:
> > So, the yocto folks moved from 4.1 to 4.4 and one of their automated
> > qemu x86-32 b
[runtime regression with "x86/mm/pat: Emulate PAT when it is disabled"] On
03/03/2016 (Thu 15:59) Paul Gortmaker wrote:
> So, the yocto folks moved from 4.1 to 4.4 and one of their automated
> qemu x86-32 boot tests started failing. None of the yocto details seem
> to matter
So, the yocto folks moved from 4.1 to 4.4 and one of their automated
qemu x86-32 boot tests started failing. None of the yocto details seem
to matter since I offered to help and I've repropduced it using 100%
mainline kernels and a generic distro toolchain as well.
The test case is slightly compl
[Re: [poky] [PATCH 1/1] poky: update qemu* to prefer 4.4 kernel] On 13/02/2016
(Sat 17:17) Richard Purdie wrote:
> I'm moving the discussion to OE-Core and pulling in some kernel people.
> I think I understand what is wrong and how to fix it but I could use
> someone who actually knows this code.
[Re: [poky] [PATCH 1/1] poky: update qemu* to prefer 4.4 kernel] On 13/02/2016
(Sat 17:17) Richard Purdie wrote:
> I'm moving the discussion to OE-Core and pulling in some kernel people.
> I think I understand what is wrong and how to fix it but I could use
> someone who actually knows this code.
[Re: [PATCH] inetutils: fix up recent build fails due to phantom empty
directory] On 04/02/2016 (Thu 13:14) Joe MacDonald wrote:
> [[PATCH] inetutils: fix up recent build fails due to phantom empty directory]
> On 16.01.31 (Sun 14:42) Paul Gortmaker wrote:
>
> > Recently I start
[Re: [OE-core] [PATCH] git: add site_perl to packaged files to fix QA install
error] On 31/01/2016 (Sun 21:40) Phil Blundell wrote:
> On Sun, 2016-01-31 at 13:27 -0500, Paul Gortmaker wrote:
> > FILES_${PN}-perltools += " \
> > ${PERLTOOLS} \
> > ${libdir
[Re: [OE-core] [PATCH] xterm: revert FILES_PN change from recent package uprev]
On 31/01/2016 (Sun 23:05) Burton, Ross wrote:
>
> On 31 January 2016 at 21:51, Paul Gortmaker
> wrote:
>
> Of course you are right. In my defense, in poky, the full path is
> meta-op
[Re: [OE-core] [PATCH] xterm: revert FILES_PN change from recent package uprev]
On 31/01/2016 (Sun 20:45) Phil Blundell wrote:
> On Sun, 2016-01-31 at 14:56 -0500, Paul Gortmaker wrote:
> > diff --git a/meta-oe/recipes-graphics/xorg-app/xterm_320.bb
> > b/meta-oe/recipes-gr
avoided by the revert of one line that was in
the above commit, as which is done here. Should there be a
desire to better absract out FILES_${PN} that can be done in
a separate follow on commit that is tested to confirm it does
not reintroduce this same build regression.
Cc: Li xin
Cc: Marti
een committed in other recipes.
Others are free to dig deeper into the true root cause if their time
permits them to do so.
Cc: Joe MacDonald
Signed-off-by: Paul Gortmaker
---
meta-networking/recipes-connectivity/inetutils/inetutils_1.9.4.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
to some other infrastructural or perl change. As the fix was
relatively obvious, I did not investigate the root cause any
further -- as the perl magic in the git bb is enough to scare
small children.
Cc: Robert Yang
Cc: Richard Purdie
Signed-off-by: Paul Gortmaker
---
meta/recipes-devtools/git/git.inc
sed, and
I found the fetcher gets 404s on the ones in this commit.
Cc: Alexander Kanavin
Cc: Ross Burton
Cc: Richard Purdie
Signed-off-by: Paul Gortmaker
diff --git
a/meta-gnome/recipes-gnome/gnome-disk-utility/gnome-disk-utility_2.32.0.bb
b/meta-gnome/recipes-gnome/gnome-disk-utility/
On 2015-08-04 10:52 AM, Richard Purdie wrote:
> On Tue, 2015-08-04 at 09:58 -0400, Paul Gortmaker wrote:
>> While diagnosing a problem with xf86-video-intel I noticed we had two
>> copies of drm headers in the sysroot; one from here and one from
>> the libdrm package. The xf
t has populated the sysroot
but two full highly parallel builds containing a full desktop graphics
suite did not show any issues.
Cc: Bruce Ashfield
Cc: Richard Purdie
Signed-off-by: Paul Gortmaker
---
meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc | 4
1 file changed, 4 inser
c: Neil Roberts
Cc: Chris Wilson
Cc: Steffen Pankratz
Cc: Ross Burton
Cc: Richard Purdie
Signed-off-by: Paul Gortmaker
diff --git
a/meta/recipes-graphics/xorg-driver/xf86-video-intel/sna-Protect-against-ABI-breakage-in-recent-versions-.patch
b/meta/recipes-graphics/xorg-driver/xf86-vi
Bind can fail configure by detecting headers w/o libs, or
it can fail the host contamination check. More details
are within the commit log in the contained patch.
Signed-off-by: Paul Gortmaker
diff --git
a/meta/recipes-connectivity/bind/bind/bind-ensure-searching-for-json-headers-searches
at the whole series, you
will see that we disable generating _any_ manpages from the
build.
Paul.
--
>
> Regards,
> Chen Qi
>
>
> On 02/11/2015 03:19 AM, Paul Gortmaker wrote:
> >We had a couple patches to 1) deal with missing perl and 2) deal
> >with the perl-l
manpage.)
And since "current wisdom is this is working as intended" we are
largely left with no choice but to use the same solution and
abandon trying to generate the man pages at build time. So here
we import prebuilt manpages.
Signed-off-by: Paul Gortmaker
---
meta/recipes-core/co
compiles, lets just decouple man page
generation from the building of coreutils entirely so it paves the
way for importing pre-generated manpages.
Signed-off-by: Paul Gortmaker
---
.../coreutils/coreutils-8.23/dummy_help2man.patch | 22 ---
.../coreutils-8.23/fix-for-dummy-ma
2: use update-alternatives in patch #2; patch #1 and #3 unchanged]
Paul.
[1] http://lists.gnu.org/archive/html/coreutils/2014-11/msg1.html
---
Paul Gortmaker (3):
coreutils: don't generate useless dummy stub manpages
coreutils: import prebuilt manpages from Gentoo
scripts:
reutils to have useful pre-made
manpages and we don't need this script anymore. And if other
gnu packages are getting useless truncated "dummy" manpages,
we want the build to fail so we can fix those packages in a
similar way, vs. having the issue hidden via a help2man that is
a no
[Re: [OE-core] [PATCH] mozjs: fix build failure due to missing dependency on
libxt] On 12/02/2015 (Thu 14:56) Peter Urbanec wrote:
> On 12/02/15 11:00, Paul Gortmaker wrote:
> >Looking at the configure script, we see these invalid values are output
> >when the autoconf test for X
This header in turn gets put in the sysroot by our build of libxt. So we
get build fails whenever mozjs is built before libxt.
Since the package clearly has never been built in a no-X11 OE environment,
we assume that all OE users to date are X11 users and hence simply add a
dependency on libxt.
On 15-02-11 07:25 AM, Burton, Ross wrote:
> Hi Paul,
>
> On 11 February 2015 at 00:17, Paul Gortmaker
> wrote:
>
>> -RDEPENDS_${PN}-dev = "avahi-daemon (= ${EXTENDPKGV}) libavahi-core (=
>> ${EXTENDPKGV}) libavahi-client (= ${EXTENDPKGV})"
>> +RD
[[PATCH] procps: disable fancy new top output mode] On 21/01/2015 (Wed 13:52)
Paul Gortmaker wrote:
> General consensus is that the new output format, with the all red
> colour and one line per core is too fugly to be left as the default.
>
> Use the configure option to switch it
[[PATCH] base-files/profile: change EDITOR to not be busybox specific] On
21/01/2015 (Wed 13:25) Paul Gortmaker wrote:
> Setting "EDITOR=/bin/vi" breaks on non-busybox systems, as
> vim will populate /usr/bin/vi instead, and you get stuff like:
>
> op3:~/poky/meta-
;${INC_PR}.1"
op3:~/poky$
Here, we change the version matching to be more relaxed by stopping at the
INC_PR value, and extending the matching to be greater or equal.
Suggested-by: Mark Hatle
Signed-off-by: Paul Gortmaker
---
meta/recipes-connectivity/avahi/avahi.inc | 2 +-
1 file chan
manpage.)
And since "current wisdom is this is working as intended" we are
largely left with no choice but to use the same solution and
abandon trying to generate the man pages at build time. So here
we import prebuilt manpages.
Signed-off-by: Paul Gortmaker
---
meta/recipes-core/co
reutils to have useful pre-made
manpages and we don't need this script anymore. And if other
gnu packages are getting useless truncated "dummy" manpages,
we want the build to fail so we can fix those packages in a
similar way, vs. having the issue hidden via a help2man that is
a no
compiles, lets just decouple man page
generation from the building of coreutils entirely so it paves the
way for importing pre-generated manpages.
Signed-off-by: Paul Gortmaker
---
.../coreutils/coreutils-8.23/dummy_help2man.patch | 22 ---
.../coreutils-8.23/fix-for-dummy-ma
[1] http://lists.gnu.org/archive/html/coreutils/2014-11/msg1.html
---
Paul Gortmaker (3):
coreutils: don't generate useless dummy stub manpages
coreutils: import prebuilt manpages from Gentoo
scripts: delete dummy help2man script
.../coreutils/coreutils-8.23/dummy_help2man.patch
Trying to use git w/o tab completion is especially annoying if
you are used to using it elsewhere -- "whatchanged" is simply
too annoying to type out in full more than once.
Signed-off-by: Paul Gortmaker
---
meta/recipes-devtools/git/git.inc | 6 ++
1 file changed, 6 insertion
created by the git folks themselves
and hosted right along side of the git tarballs, so updates will
be relatively seamless.
Paul.
---
Paul Gortmaker (2):
git: expand recipe to take advantage of pre-gen'd manpages
git: add basic tab completion support
meta/recipes-devtools/git/gi
These could be created from scratch from git itself, but it
requires asciidoc, xsltproc, python bits and too much other
baggage. Since the git folks issue a tarball with the manpages
for each release, it is simpler to just go get that.
Signed-off-by: Paul Gortmaker
---
meta/recipes-devtools
the
manual set of S was done _after_ the include; once we move it
to be _before_ the include ("require"), the problem goes away.
Signed-off-by: Paul Gortmaker
---
meta/recipes-connectivity/avahi/avahi-ui_0.6.31.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/met
[Re: [OE-core] [PATCH] devtools: add a bb for git-manpages] On 02/02/2015 (Mon
17:04) Paul Eggleton wrote:
> Hi Paul,
>
> On Friday 30 January 2015 19:08:25 Paul Gortmaker wrote:
> > These could be created from scratch from git itself, but it
> > requires asciidoc, xsltproc
These could be created from scratch from git itself, but it
requires asciidoc, xsltproc, python bits and too much other
baggage. Since the git folks issue a tarball with the manpages
for each release, it is simpler to just go get that.
Signed-off-by: Paul Gortmaker
---
.../git-manpages/git
General consensus is that the new output format, with the all red
colour and one line per core is too fugly to be left as the default.
Use the configure option to switch it back to the sane default that
we've all become used to seeing for decades.
Signed-off-by: Paul Gortmaker
---
meta/re
m install w/o busybox.
Signed-off-by: Paul Gortmaker
---
meta/recipes-core/base-files/base-files/profile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/base-files/base-files/profile
b/meta/recipes-core/base-files/base-files/profile
index 88ab8d877b0d..
entitydefs). Here we fix it in the same way as what was done
for buildtools-tarball and include python-modules vs. all the
individual little chunks.
Signed-off-by: Paul Gortmaker
---
.../packagegroups/packagegroup-self-hosted.bb | 28 +-
1 file changed, 1 insert
On 14-08-07 01:33 AM, Koen Kooi wrote:
>
> Op 6 aug. 2014, om 22:38 heeft Paul Gortmaker
> het volgende geschreven:
>
>> commit 841ec528ec04e64bd09ff10f8d9ad2d6e3aac05d ("coreutils: update
>> to upstream version 9.21") added a patch which bypassed the check
Signed-off-by: Paul Gortmaker
diff --git a/meta/recipes-core/coreutils/coreutils-8.22/dummy_help2man.patch
b/meta/recipes-core/coreutils/coreutils-8.22/dummy_help2man.patch
deleted file mode 100644
index 4757f52aa0be..
--- a/meta/recipes-core/coreutils/coreutils-8.22/dummy_help
On 14-08-06 04:21 AM, Martin Jansa wrote:
> On Tue, Aug 05, 2014 at 01:26:12PM -0400, Paul Gortmaker wrote:
>> Currently util-linux is fragmented into lots of small chunks,
>> and if one is looking to avoid using busybox wholesale, there
>> is currently no easy way to say &quo
anting the same
overall goal of removing busybox.
Signed-off-by: Paul Gortmaker
diff --git a/meta/recipes-core/packagegroups/packagegroup-util-linux.bb
b/meta/recipes-core/packagegroups/packagegroup-util-linux.bb
new file mode 100644
index ..54151502b176
--- /dev/null
+++ b/meta/re
started ... Debian in 2003..
Here we simply convert them to being normal 755 dirs.
[YOCTO #6579]
Signed-off-by: Paul Gortmaker
---
meta/files/fs-perms.txt | 10 +-
meta/recipes-core/base-files/base-files_3.0.14.bb | 3 ++-
2 files changed, 7 insertions(+), 6 del
Nothing interesting to see in the git history ; appears to have
been this way since its creation.
Signed-off-by: Paul Gortmaker
---
meta/recipes-core/base-files/base-files_3.0.14.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/base-files/base
Also note that the settings for /var/mail seem incorrect, and so
they have been aligned with what is seen in most common distros.
Signed-off-by: Paul Gortmaker
---
meta/files/fs-perms.txt | 6 +++---
meta/recipes-core/base-files/base-files_3.0.14.bb | 19 ++--
ot; set anymore.
poky$ls -ld
build/tmp/work/intel_corei7_64-poky-linux/core-image-sato/1.0-r0/rootfs/home/
drwxr-xr-x 4 paul paul 4096 Jul 25 20:27
build/tmp/work/intel_corei7_64-poky-linux/core-image-sato/1.0-r0/rootfs/home/
poky$
Bug:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=6579
quot;." case
is also stored in a malloc'd pointer, so that the intended
runtime behaviour of the code remains unchanged.
Patch has been accepted by upstream maintainers of gcc.
Signed-off-by: Paul Gortmaker
---
[v2: worked with gcc folks to get a variation on the 1st
patch which is
On 14-06-23 11:01 AM, Paul Gortmaker wrote:
> When enabling a lib32-gcc in a 64 bit build, without doing any
> other configuration, the mutilib dir is unspecified, which is
> represented internally in gcc as "." and as such uncovers an
> invalid free on a non-malloc'd
r equality with "." rather than
inequality.
Signed-off-by: Paul Gortmaker
diff --git a/meta/recipes-devtools/gcc/gcc-4.9.inc
b/meta/recipes-devtools/gcc/gcc-4.9.inc
index 185dbba82200..cbf1355fcbf7 100644
--- a/meta/recipes-devtools/gcc/gcc-4.9.inc
+++ b/meta/recipes-devtools/gcc/g
/poky/meta/recipes-devtools/perl/libxml-parser-perl_2.41.bb,
do_package) failed with exit code '1'
...which showed up when enabling a multilib build.
Signed-off-by: Paul Gortmaker
diff --git a/meta/recipes-devtools/perl/libxml-parser-perl_2.41.bb
b/meta/recipes-devtools/perl/lib
h -EPERM.
Before looking in mainline gawk for a fix, I fixed it myself.
Then in comparing with mainline gawk, I found their fix was
not 100% complete. So here we get a backport of the mainline
gawk commit, plus the delta as a commit that I've sent to the
gawk mailing list.
Signed-off-by:
o use the VTs and connect a keyboard and want ctrl-alt-del
support. In keeping with the SYSVINIT_ENABLED_GETTYS option, we
make it optional, since for some situations (kiosk etc.) it may
not be desired to be enabled.
Signed-off-by: Paul Gortmaker
---
meta/conf/documentation
On 12-08-17 05:41 PM, Richard Purdie wrote:
> On Fri, 2012-08-17 at 14:07 -0400, Paul Gortmaker wrote:
>> On 12-08-17 12:57 PM, Richard Purdie wrote:
>>> On Mon, 2012-08-13 at 18:43 -0400, Paul Gortmaker wrote:
>>>> Without this, you will get occasional build fail
On 12-08-17 12:57 PM, Richard Purdie wrote:
> On Mon, 2012-08-13 at 18:43 -0400, Paul Gortmaker wrote:
>> Without this, you will get occasional build failures if libproxy
>> tries to build before the glib headers are placed in the sysroot.
>>
>> Signed-off-by: Paul Go
Without this, you will get occasional build failures if libproxy
tries to build before the glib headers are placed in the sysroot.
Signed-off-by: Paul Gortmaker
diff --git a/meta/recipes-support/libproxy/libproxy_0.4.7.bb
b/meta/recipes-support/libproxy/libproxy_0.4.7.bb
index 7e3cf27..a39e3a8
[CC'ing Richard, since Phil says he is list admin]
On 12-07-09 12:01 PM, Phil Blundell wrote:
> On Thu, 2012-07-05 at 12:14 -0400, Paul Gortmaker wrote:
>>> On Wed, 2012-07-04 at 11:00 -0400, Paul Gortmaker wrote:
>>>>> On a related note, is it possible to
[Re: [OE-core] [PATCHv2 0/3] u-boot recipe updates] On 04/07/2012 (Wed 16:29)
Phil Blundell wrote:
> On Wed, 2012-07-04 at 11:00 -0400, Paul Gortmaker wrote:
> > I've found Richard's comments [looking in OE archive and not poky
> > helped] and will test what he proposed
[Re: [oe-commits] Paul Gortmaker : linux-firmware: update to main repo on
kernel.org] On 04/07/2012 (Wed 19:27) Martin Jansa wrote:
> On Thu, Jun 28, 2012 at 09:20:18PM +0200, Martin Jansa wrote:
> > On Mon, Jun 25, 2012 at 03:33:28PM +, g...@git.openembedded.org wrote:
>
The setting is the same in all recipes, so move it to
the shared settings in u-boot.inc
Since FILESDIR is also being phased out, use the FILESPATH
setting as suggested by Richard Purdie.
Cc: Richard Purdie
Signed-off-by: Paul Gortmaker
---
[ PG: Retested builds for 8315 and beagleboard
[Re: [PATCHv2 0/3] u-boot recipe updates] On 04/07/2012 (Wed 10:12) Paul
Gortmaker wrote:
> [Re: [PATCHv2 0/3] u-boot recipe updates] On 03/07/2012 (Tue 10:48) Saul Wold
> wrote:
>
> > On 07/01/2012 10:44 PM, Paul Gortmaker wrote:
> > >These are the oe-core updates re
[Re: [PATCHv2 0/3] u-boot recipe updates] On 03/07/2012 (Tue 10:48) Saul Wold
wrote:
> On 07/01/2012 10:44 PM, Paul Gortmaker wrote:
> >These are the oe-core updates required so that yocto can do
> >a successful build of a working u-boot image for the mpc8315
> >reference BS
The u-boot tree is fully capable of parallel builds, so this
setting should not exist as a blanket setting for all of the
recipes. Going forward, if there is a parallelism issue
in u-boot, it needs to be reported and fixed there, and not
with the "make -j1" band-aid approach.
Signed-of
We don't want to force everyone to be stripping the -Os
flags from their u-boot builds. Remove it, since it pertains
to an old toolchain issue that is no longer relevant, and it
breaks the powerpc mpc8315.
Signed-off-by: Paul Gortmaker
---
meta/recipes-bsp/u-boot/u-boot.inc |3 +--
1
The setting is the same in all recipes, so move it to
the shared settings in u-boot.inc
Signed-off-by: Paul Gortmaker
---
meta/recipes-bsp/u-boot/u-boot.inc |1 +
meta/recipes-bsp/u-boot/u-boot_2011.03.bb|2 --
meta/recipes-bsp/u-boot/u-boot_2011.06.bb|2 --
meta
tch that was sent to the yocto list earlier to
enable building it (u-boot.bin) by default is unchanged, but I can
resend that if it helps somehow.
Paul.
---
Paul Gortmaker (3):
u-boot: Don't make the -Os removal part of global settings.
u-boot: make FILESDIR a shared setting.
u-boot: do
[Re: [OE-core] [PATCH 1/3] u-boot: Don't make the -Os removal part of global
settings.] On 01/07/2012 (Sun 15:03) Saul Wold wrote:
> On 06/29/2012 11:35 AM, Paul Gortmaker wrote:
> >We don't want to force everyone to be stripping the -Os
> >flags from their u-boot bui
1 - 100 of 107 matches
Mail list logo
