Tom Rini writes:
> +python () {
> +sitedata = set(siteinfo_data(d))
> +if "endian-little" in sitedata:
> +d.setVar("SITEINFO_ENDIANESS", "le")
> +elif "endian-big" in sitedata:
> +d.setVar("SITEINFO_ENDIANESS", "be")
Assigning SITEINFO_ENDIANESS in this way seems to b
Phil Blundell writes:
>> We don't want to change the owner/mode of symlinks, as this may
>> affect the target of the link. Also broken links will fail as well.
>
> This seems like it will cause links themselves to end up getting shipped
> under the UID/GID that was used for building
there shoul
From: Enrico Scholz
Wildcards in SRC_URI are not supported by oe-core and work only
when last (or first?) FILESPATH element points to the containing
directory. Specifying plain dir works fine for this recipe.
Signed-off-by: Enrico Scholz
---
.../console-tools/console-tools_0.3.2.bb
There is no need to have static module-init-tools for the cross
tools. Building such binaries requires a static libc which is not
required by the rest of OE and which is deprecated and not installed
by distributions like Fedora.
Signed-off-by: Enrico Scholz
---
.../module-init-tools
ncurses does not create its .pc files when the /usr/lib/pkg-config
directory does not exist in the sysroot. Because ncurses will be built
very early, this directory might be missing and .pc files will not be
installed.
Signed-off-by: Enrico Scholz
---
.../ncurses/ncurses-5.9/pkgconfig
Richard Purdie
writes:
> If the man pages are compressed, then they cause file conflicts between
> the 32-bit and 64-bit versions of the package.
Patching the buildsystem to use 'gzip --no-name' might be a better
solution than uncompressing the man pages.
Alternatively, fixing/changing man page
Phil Blundell writes:
>> +- if test -n "$PKG_CONFIG_LIBDIR" && test -d "$PKG_CONFIG_LIBDIR" ; then
>> ++ if test -n "$PKG_CONFIG_LIBDIR" ; then
>
> I wonder if it would be easier to just create the directory in
> do_configure()
This directory is in the staged sysroot
(e.g. ${TMPDIR}/sysroot
Saul Wold writes:
> - f=${D}${libdir}/$i.so
> +f=${D}${base_libdir}/$i.so
this breaks builds because 'ld' does not search ${base_libdir}:
| gcc -shared ... -ltermcap
| /usr/bin/ld: cannot find -ltermcap
| ERROR: Task 216 (virtual:native:.../readline/readline_6.2.bb,
Andreas Müller writes:
> currently some libs are moving from $libdir (/usr/lib) -> $base_libdir
> (/lib).
Parts of these changes are wrong resp. require adaptations in the build
system. Devel .so files can stay in /usr/lib; moving them to /lib breaks
builds because /lib is not in the 'ld' search
Scott Garman
writes:
>>> - f=${D}${libdir}/$i.so
>>> +f=${D}${base_libdir}/$i.so
>>
>> this breaks builds because 'ld' does not search ${base_libdir}:
>>
>> | gcc -shared ... -ltermcap
>> | /usr/bin/ld: cannot find -ltermcap
>> | ERROR: Task 216 (virtual:native:.../readl
Christopher Larson
writes:
> --- a/meta/recipes-core/ncurses/ncurses.inc
> +++ b/meta/recipes-core/ncurses/ncurses.inc
> ...
> +# natives don't generally look in base_libdir
> +base_libdir_virtclass-native = "${libdir}"
I do not think that this should be done per recipe (afais, at least
libusb i
There does not exist an '--enable-target=all' option.
Signed-off-by: Enrico Scholz
---
meta/recipes-devtools/binutils/binutils.inc |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-devtools/binutils/binutils.inc
b/meta/recipes-devtools/binutils/bi
Packaging will fail with executable files containing spaces in their
names. Patch quotes the parameter passed to 'objdump'.
Signed-off-by: Enrico Scholz
---
meta/classes/package.bbclass |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/classes/package
There is no reason to disable exec-stack only for -native builds;
binaries on the target will suffer from the same SELinux ACLs.
OpenSSL does not use executable stack so this option can be disabled
unconditionally.
Signed-off-by: Enrico Scholz
---
meta/recipes-connectivity/openssl/openssl.inc
Changes to BUILD_LDFLAGS are required due to the recent movement of some
libraries from ${libdir} to ${base_libdir}. ${base_libdir} must be now
in the linker search path to avoid build problems of -native packages.
Signed-off-by: Enrico Scholz
---
meta/conf/bitbake.conf |8 +++-
1
From: Enrico Scholz
'grep -r' will return symlinks (e.g. from the patches/ directory) and it
would be wrong to modify them with sed. Such a modification might fail
and break the buildprocess when symlink target is not writable by the
build user.
Signed-off-by: Enrico Scholz
---
me
From: Enrico Scholz
Flag is used to skip generation of recursive RRECOMMENDS for packages
which are ending in '-dev' but which are no -dev packages. Examples are
kernel modules like 'kernel-module-i2c-dev' (i2c-dev.ko).
Signed-off-by: Enrico Scholz
---
meta/classes/pa
From: Enrico Scholz
It would be wrong to generate depchains like i2c-dev ->
module-init-tools-dev -> libc-dev. Skip generation of recursive
RRECOMMENDS in such cases by using the nodevrrecs flag.
Signed-off-by: Enrico Scholz
---
meta/classes/kernel.bbclass |1 +
1 files chan
Several packages can be used without graphical frontends, but the
buildsystem brings in statically (heavy) x11 or gtk+ software stacks.
This patchset uses the 'x11' DISTRO_FEATURE to disable building of
these components.
Enrico Scholz (4):
gst-plugins: do not build x11 related plugi
gst-plugins might be used on headless systems or on systems with
DirectFB or qt frontends. Building them without the x11 software stack
might be desirable there and is supported by the buildsystem.
Signed-off-by: Enrico Scholz
---
.../gstreamer/gst-plugins-base_0.10.35.bb |4
'distcc' can be used on headless system and it is desirable to avoid
building of the gnome/gtk+ stacks.
Signed-off-by: Enrico Scholz
---
meta/recipes-devtools/distcc/distcc_2.18.3.bb |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-devto
'latencytop' can be used on headless system and it is desirable to avoid
building of the gtk+ stack.
Signed-off-by: Enrico Scholz
---
meta/recipes-kernel/latencytop/latencytop_0.5.bb |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-kernel/
'sysprof' can be used on headless system and it is desirable to avoid
building of the gtk+/glade software stacks.
Signed-off-by: Enrico Scholz
---
meta/recipes-kernel/sysprof/sysprof_git.bb |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-kern
VIJAY KUMAR
writes:
> I am trying to build openjdk-6 for my imx53sabre board.
> During my journey, I got sticked here to get out of error.
>
> | chmod -w grove_inst.cxx
> | chmod: grove_inst.cxx: new permissions are r-xr-xrwx, not r-xr-xr-x
chmod -### operations are broken because they take umas
Richard Purdie
writes:
> This is likely as a result of the installorder patch :/. Sadly if we
> want the postinstalls to be installed in order we do need that patch.
>
> The question is whether circular depends are something opkg should
> support or not?
I think, circular dependencies should (an
Hi,
the 82d73423c57569b984ee0ae3d93e3c3bd5dc5216 "runqueue: Reimplement
recrdepends so it works more correctly" bitbake commit breaks
OpenEmbedded's 'do_fetchall' task. Previously sources of all dependent
tasks were downloaded. Now, only a small subset gets fetched.
Before:
| $ ./bitbake my-im
Richard Purdie
writes:
> Originally, git was something new, not installed everywhere and had
> commandline stability problems. This has changed and git it no longer
> makes sense to continually build this when the system installed version
> is likely sufficient.
Can this really be assumed? Recen
Hi,
some of the recent changes seem to break the parallel build of the gcc*
recipes which are sharing a same source directory:
| $ ./bitbake gcc-cross-initial gcc-cross-intermediate gcc-cross -c cleansstate
| $ BB_NUMBER_THREADS=3 ./bitbake gcc-cross-initial gcc-cross-intermediate
gcc-cross
| ..
Richard Purdie
writes:
> Encrico: Which DISTRO are you using and do you use rm_work*.bbclass?
yes; rm_old_work seems to cause the problem. Task uses ${PN} and was
declared with
addtask rm_old_work before do_unpack
which causes different base hashes.
Is there a way to exclude such tasks fr
Richard Purdie
writes:
>> Is there a way to exclude such tasks from the signature handling?
>
> The easiest option is probably something like:
>
> do_rm_old_works[vardepexclude] = "PN"
I tried this but it is not really an option because there must be added
a lot of completely unrelated variables
Richard Purdie
writes:
>> >> Is there a way to exclude such tasks from the signature handling?
>> >
>> > The easiest option is probably something like:
>> >
>> > do_rm_old_works[vardepexclude] = "PN"
>>
>> I tried this but it is not really an option...
>
> Can you point me at a copy of the clas
bitbake has a similar behavior when evaluating 'export'
and 'unexport' flags so that this variable must be set in a python
function instead of declaring it in bitbake.conf.
Signed-off-by: Enrico Scholz
---
meta/classes/base.bbclass |8
meta/conf/bitbake.conf
Enrico Scholz
writes:
>> Encrico: Which DISTRO are you using and do you use rm_work*.bbclass?
>
> yes; rm_old_work seems to cause the problem.
The signature stuff was one problem; there is another, more trivial (but
probably more difficult) one:
Adding a task like
| addtask do
Richard Purdie
writes:
>> ccache checks for existence of environment; not for its value:
>> ...
>> Hence, avoid setting of $CCACHE_DISABLE instead of assigning '0'.
>
> Why doesn't CCACHE_DISABLE[unexport] = "1" help here?
You mean, keeping the
| export CCACHE_DISABLE ??= "${@[0,1][d.getVar('C
Richard Purdie
writes:
> do_rm_old_work[stamp-base] = "${SS}"
will not work because do_rm_old_work depends on ${PN} (it cleans the
packages + packages-split directories of previously built packages in
${WORKDIR}). Executing it for only one gcc* recipe will keep the
directories of the other reci
Richard Purdie
writes:
>> and requesting explicitly that user specifies
>>
>> | CCACHE_DISABLE[unexport] = "1"
>>
>> in his .conf? Sounds hacky and inconsistent and makes it impossible to
>> set CCACHE_DISABLE by external environment.
>
> The idea is that anyone enabling ccache would inherit
Richard Purdie
writes:
>> afais, the ccache.bbclass class is for assigning and cleaning some
>> (imho) strange CCACHE_DIR only which lowers efficiency significantly.
>>
>> Normal ccache usage with a single CCACHE_DIR works fine (and much better)
>> without this class.
>
> There are the following
Radu Moisan
writes:
> Close-on-exec seems to be unsuported on some architectures like CentOS 5.8
> and thus causing some packages to fail to build successfully.
Have you verified that making O_CLOEXEC a noop does not break the
applications?
Enrico
Koen Kooi
writes:
> RPROVIDES_${PN} += "dbus-x11"
This is wrong because 'dbus' does not provide dbus-x11 when x11 is
disabled by distro. Packages which require dbus-launch from 'dbus-x11'
will install fine but will fail at runtime.
Enrico
___
Opene
Radu Moisan
writes:
> Followed suggestions from Bugz 2261:
>
> 1) remove the --with-x/--without-x configure arguments.
why? They are valid ./configure options and common when evaluating the
x11 distro-feature. Selecting them explicitly makes the build more
predictable and detects configuration
Radu Moisan
writes:
> it does not crash at runtime.
I do not speak about crash; I guess 'dbus-launch' has some extra
functionality when compiled with x11 support, and packages which
depend on dbus-x11 might expect this functionality.
Providing 'dbus-x11' although no x11 functionality is provide
writes:
> +++ b/meta/recipes-kernel/perf/perf_3.4.bb
> ...
> + sed -i "s:-I/usr/include/slang:-I${STAGING_INCDIR}:"
> ${S}/tools/perf/Makefile
You are patching an already staged file here:
| S = "${STAGING_KERNEL_DIR}"
When want to fix it in this way (another workaround might be adding
'
Hi,
having something in the image which brings gcc-runtime-locale-XX in
causes do_rootfs to fail with:
* satisfy_dependencies_for: Cannot satisfy the following dependencies for
gcc-runtime-locale-de:
* gcc-runtime *
* opkg_install_cmd: Cannot install package gcc-runtime-locale-de.
This
Khem Raj writes:
> svn tar balls are 96M as compared to 1.3G git tars
perhaps it's time to implement support for shallow git repositories to
bitbake...
Enrico
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.l
Hi,
with recent oe-core + oe-meta, a build from scratch fails in eglibc
with:
|
.../tmp/sysroots/x86_64-oe-linux/usr/bin/armv5te-linux-gnueabi/arm-linux-gnueabi-ld.bfd:
cannot find -lgcc_eh
| collect2: error: ld returned 1 exit status
| make[2]: ***
[.../tmp/work/armv5te-linux-gnueabi/eglibc-2
Hi,
I just noticed that libgcc_s.so.1 is not stripped in the .ipk. Is
there any reason to keep the debug symbols? Uncompressed, this makes a
difference of more than 1 MB.
Enrico
___
Openembedded-core mailing list
Openembedded-core@lists.openembedde
Old script failed to parse unit files containing comments like
| #Alias=some-alias
or whitespaces like
| WantedBy = foo
correctly. Patch changes script to interpret keywords only when they
are at the beginning of a line and ignores whitespaces before the '='.
Signed-off-by: Enr
c told
they are using the traditional '/usr/libexec' in their distribution so
that this case is handled as well.
Patch is not perfect, but solves the problem for now.
Signed-off-by: Enrico Scholz
---
meta/recipes-core/dropbear/dropbear.inc | 8
1 file changed, 8 insertions(+)
${libexecdir}/* wildcard can match everything in ${libdir} which
causes packaging of unwanted files. Remove this wildcard and specify
libexec binaries manually
Signed-off-by: Enrico Scholz
---
meta/conf/bitbake.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/conf
${libexecdir}/* wildcard can match everything in ${libdir} which
causes packaging of unwanted files. Remove this wildcard and specify
libexec binaries manually
Signed-off-by: Enrico Scholz
---
meta/recipes-connectivity/connman/connman.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion
${libexecdir}/* wildcard can match everything in ${libdir} which
causes packaging of unwanted files. Remove this wildcard and specify
libexec binaries manually
Signed-off-by: Enrico Scholz
---
meta/recipes-extended/gamin/gamin_0.1.10.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion
oved after this
change because '${libexecdir}' can become equal to '${libdir}' and these
directories require a different packaging.
Signed-off-by: Enrico Scholz
---
meta/conf/bitbake.conf | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/conf/bitbake.co
${libexecdir}/* wildcard can match everything in ${libdir} which
causes packaging of unwanted files. Remove this wildcard and specify
libexec binaries manually
Signed-off-by: Enrico Scholz
---
meta/recipes-core/eglibc/eglibc-package.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion
${libexecdir}/* wildcard can match everything in ${libdir} which
causes packaging of unwanted files. Remove this wildcard and specify
libexec binaries manually
Signed-off-by: Enrico Scholz
---
meta/recipes-core/uclibc/uclibc-package.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion
${libexecdir}/* wildcard can match everything in ${libdir} which
causes packaging of unwanted files. Remove this wildcard and specify
libexec binaries manually
Signed-off-by: Enrico Scholz
---
meta/recipes-multimedia/gstreamer/gstreamer_0.10.36.bb | 2 +-
1 file changed, 1 insertion(+), 1
"Burton, Ross"
writes:
> I agree with dropping $libdir and hard-coding "lib", but have you done
> a world oe-core build
no; I do not have the resources for this :( I did a static analysis of
recent recipes and fixed the obvious things.
Change will cause probably some silent breakage which can n
"Burton, Ross"
writes:
>> Things *are* expected to move around. E.g. /usr/lib/openssh/sftp-server
>> becomes /usr/lib/sftp-server now.
>
> Right, so don't use Debian as a rationale for this approach.
Debian defines libexecdir to be /usr/lib (+multiarch). It might set
sometimes per-package '--l
Saul Wold writes:
Things *are* expected to move around. E.g. /usr/lib/openssh/sftp-server
becomes /usr/lib/sftp-server now.
>>>
>>> Right, so don't use Debian as a rationale for this approach.
>>
>> Debian defines libexecdir to be /usr/lib (+multiarch). It might set
>> sometimes per-p
"Burton, Ross" writes:
> rpm allows "executables" (but not libraries) to conflict and will
> prefer the 64-bit version,
Sure? At least rpm-4 (Fedora, RHEL) does not allow files to conflict.
Fedora solves the multilib problem by splitting the distribution into
main packages (unilib only; contain
Robert Yang
writes:
> The recipe's DESCRIPTION is wrapped automatically by textwrap, make it
> support newline ("\n") to let the user can wrap it manually, e.g.:
>
> -ctrlfile.write('Description: %s\n' % summary)
> -ctrlfile.write('%s\n' % textwrap.fill(des
Generating filesystems with this flag allows more efficient directory
traversals because getdents() returns the filetype in 'd_type' which
allows to avoid an extra lstat() call.
Creating ext4 filesystems with 'mkfs.ext4' sets this flag by default
too.
Signed-off-by: Enri
Hi,
is it expected that recent gcc 4.8[1] compiles the kernel correctly?
Kernels for ARMv5 platforms (PXA168 -> 3.4.52, MX28 -> 3.8.13) fail here
100% at early boot with
[0.404750] Unable to handle kernel paging request at virtual address
00210020
[0.412468] pgd = c0004000
[0.415187]
Enrico Scholz
writes:
> is it expected that recent gcc 4.8[1] compiles the kernel correctly?
> Kernels for ARMv5 platforms (PXA168 -> 3.4.52, MX28 -> 3.8.13) fail here
> 100% at early boot with
Applying two upstream kernel commits
455bd4c430b0c0a361f38e8658a0d6cb469942b5 (A
Bruce Ashfield
writes:
>> Applying two upstream kernel commits
>> 455bd4c430b0c0a361f38e8658a0d6cb469942b5 (ARM: 7668/1: fix
>> memset-related crashes caused by recent GCC (4.7.2) optimizations) and
>> 418df63adac56841ef6b0f1fcf435bc64d4ed177 (ARM: 7670/1: fix the memset
>> fix) seem to fix the p
Saul Wold writes:
> The PACKAGECONFIG will ensure consistent enabling and disabling of the pam
> and systemd related
> options for configure and the correct dependencies
>
> v2: fixed PACKAGECONFIG line continuation grammar
> added _class-target for PACKAGECONFIG to work on target only
> ...
"Shakeel, Muhammad"
writes:
> If systemd is supported DISTRO_FEATURE and sysvinit is not and also if
> systemd_unitdir contains a service file(s) then no need to keep init.d scripts
> for sysvinit compatibility.
> ...
> +for filename in os.listdir(systemd_unitdir):
> +
Koen Kooi
writes:
> The ??= operator is too weak
> ...
> -PACKAGECONFIG_class-target ??= "${@base_contains('DISTRO_FEATURES', 'pam',
> 'libpam', '', d)} \
> +PACKAGECONFIG_class-target ?= "${@base_contains('DISTRO_FEATURES', 'pam',
> 'pam', '', d)} \
> ${@ba
writes:
> To avoid generating ssh keys every time a system with read-only rootfs
> starts, we generate ssh keys at rootfs creation time.
This is security wise a very bad and dangerous change because all devices
will get the same key which can be extracted very easy from (public)
images.
Enrico
Paul Eggleton
writes:
> -for foo in `grep -I -m1 \/usr\/include\/.*\\.h ${WORKDIR}/* -r | cut
> -f 1 -d ":"` ; do
> +for foo in `grep -I --exclude="*.patch" --exclude="*.diff"
> --exclude="*.pod" --exclude="README*" -m1 "/usr/include/.*\.h" ${WORKDIR}/*
> -r -l` ${S}/utils/h2xs
Andreas Oberritter writes:
> What's the use case for removing packages offline
I am developing very much with NFS root filesystems (--> the temporary
image directory which is kept by IMAGE_KEEPROOTFS=1). Packaging operations
like install, remove or upgrade are common actions to test recipes and
Hi,
after enabling gold linker (ld-is-gold DISTRO_FEATURE), the '-flto
-fuse-linker-plugin' build options do not work anymore as with the old
bfd linker. I am using the toolchain layer of oe-meta.
Is this expected or just some issue with our gcc?
Enrico
with ld-is-gold
$ arm-linux-g
ror 126
I am not sure whether the custom do_compile_prepend() is still needed.
For now only the issue above will be fixed by executing ./config.status
yet again.
[1] see 648290d5bf4d6ff50d3643bb7ad902dfc23aa702
Signed-off-by: Enrico Scholz
---
meta/recipes-devtools/libtool/libtool-2.4.2.inc |3
Andreas Oberritter writes:
>>> What's the use case for removing packages offline
>>
>> I am developing very much with NFS root filesystems (--> the temporary
>> image directory which is kept by IMAGE_KEEPROOTFS=1). Packaging operations
>> like install, remove or upgrade are common actions to te
Andreas Oberritter writes:
> What's the use case for removing packages offline
>>
>> yes; I am working on the build machine. The NFS filesystem is mounted
>> read-only on the target.
>
> How do you handle prerm and postrm scripts that fail because $D is
> set?
Fortunately, there are very fe
Koen Kooi writes:
>> Considering that in the meantime my similar patch [1] to systemd.bbclass
>> got merged into meta-oe by Koen, who initially was against it, I guess
>> this patch can finally get merged now, too.
>
> Crap, I missed the $D part, that's going to get reverted
I think we can keep
Koen Kooi writes:
Considering that in the meantime my similar patch [1] to systemd.bbclass
got merged into meta-oe by Koen, who initially was against it, I guess
this patch can finally get merged now, too.
>>>
>>> Crap, I missed the $D part, that's going to get reverted
>>
>> I t
Richard Purdie
writes:
> Currently, ccache is used if it is present. When building from scratch
> it gives no performance improvement
Here, I have a 10% cache hit ratio in a scratch build:
cache hit (direct) 2841
cache hit (preprocessed)1370
cache miss
r' if option outputs to stderr
| make[3]: *** [asn1Coding.1] Error 1
which was caused by touching configure.ac which is a dependency of the
generated man pages.
Signed-off-by: Enrico Scholz
---
meta/recipes-support/gnutls/libtasn1_2.12.bb | 10 +-
1 files changed, 9 insertions
`--help' info from ../src/asn1Coding
>> | Try `--no-discard-stderr' if option outputs to stderr
>> | make[3]: *** [asn1Coding.1] Error 1
>>
>> which was caused by touching configure.ac which is a dependency of the
>> generated man pages.
>>
>
Richard Purdie writes:
>> setting HELP2MAN environment to 'true' for cross-builds might be a
>> general solution But this does not seem to be implemented...
>
> Right, I remember looking into this and its hard to disable. I've pushed
> a PATH change to address this problem...
But this makes
Richard Purdie
writes:
> This switches to use the hash based signature generatior and update
> layout_abi to match stamp file layout changes.
Has this really been tested? I played a little bit with it and it was
very painful when whole distribution will be rebuilt due to a minor
change in an ear
Richard Purdie
writes:
>> There are some subtle bugs in the hash generation too (e.g. bitbake's
>> get_file_depends() result is used to calculate a hash over a set() which
>> is filled nondeterministically when BB_NUMBER_THREADS>1) which cause
>> random rebuilds too.
>
> Bug reports on issues lik
Last mirror rewrite caused a regression not accepting
.*://.*/.* file://${DL_DIR}/../local/
like specifications anymore. Patch restores old behavior by using regexp
matching when checking protocol.
Signed-off-by: Enrico Scholz
---
lib/bb/fetch2/__init__.py |2 +-
1 Datei geändert, 1
> I'm not sure what to do about fixing this...
should be trivial by regexp matching the protocol part instead of
comparing it with '='. See my parallel posting for a patch.
Enrico
___
Openembedded-core mailing list
Openembedded-core@lists.openembedde
Richard Purdie writes:
>> # Principle of least surprise. We could end up with https
>> matching against http and
>> # generating "files://" urls if we use the regexp engine below.
>> -if i != uri_decoded[loc]:
>> +if not re.match(i, uri_decoded[
Enrico Scholz writes:
>>> -if i != uri_decoded[loc]:
>>> +if not re.match(i, uri_decoded[loc]):
>
> | FAIL: test_urilist2 (bb.tests.fetch.FetcherTest)
> | AssertionError: Lists differ: ['file:///somepath/downloads/b... !=
> ['file
writes:
> Use weaker assignment for CCACHE_DIR to allow users to override it
> if desired.
>
> -export CCACHE_DIR = "${TMPDIR}/ccache/${MULTIMACH_HOST_SYS}/${PN}"
> +export CCACHE_DIR ?= "${TMPDIR}/ccache/${MULTIMACH_HOST_SYS}/${PN}"
This can be a dangerous change and probably does not have the
"Shakeel, Muhammad"
writes:
> +++ b/meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-utils.service
> @@ -0,0 +1,16 @@
> +[Unit]
> +Description=NFS Server
> +Requires=rpcbind.service
> +After=rpcbind.service
> +
> +[Service]
> +Type=oneshot
> +ExecStart=/usr/sbin/rpc.nfsd
> +ExecStart=/usr/sbin/r
"Shakeel, Muhammad"
writes:
> +++ b/meta/recipes-extended/rpcbind/rpcbind/rpcbind.service
> ...
> +[Service]
> +Type=forking
> +ExecStart=/usr/sbin/rpcbind
The '-w' option, perhaps '-f' (--> 'Type=forking' can be removed then)
and a general way to add local options would be a good idea.
-->
|
Ross Burton
writes:
> If binfmt_misc was compiled as a module but isn't installed then
> systemd-binfmt
> will put an automounter on /proc/sys/fs/binfmt_misc and when it attempts to
> automount (e.g. when df is called) it can't find support for the filesystem,
> and
> throws an error.
>
> As bi
Jukka Rissanen
writes:
> The connman init.d script tried to ignore all the network interfaces
> if NFS root is configured. We should only ignore the interface that is
> used by NFS root.
This does not really work; e.g. here:
1. the cmdline is 'ip=dhcp' and won't be detected by your expression
Otavio Salvador writes:
> The LDFLAGS is required or some old kernels fails due missing
> symbols and this is preferred than requiring patches to every old
> supported kernel.
> ...
> +LDFLAGS="-ldl -lutil"
What is with -Wl,-as-needed or the gnu-hash ldflags which are applied
usually? Perhaps,
Bruce Ashfield
writes:
>>> +LDFLAGS="-ldl -lutil"
>>
>> What is with -Wl,-as-needed or the gnu-hash ldflags which are applied
>> usually? Perhaps, hacks like
>
> We don't want to influence the perf build from the build system, unless we
> absolutely have to. We want to use the flags and configs
Otavio Salvador writes:
> +# The LDFLAGS is required or some old kernels fails due missing
> +# symbols and this is preferred than requiring patches to every old
> +# supported kernel.
> +LDFLAGS="-ldl -lutil"
LDFLAGS is usually the wrong variable for extra libs (it might conflict
with '-Wl,-as-
Otavio Salvador writes:
> I don't agree on this. perf is tied to kernel and part of its code so
> I think same exception rule apply for it as well.
perf ships with the kernel but is a pure userspace program. It does not
require any special setup ('make configure'), it links against complex
user
writes:
> Besides, we need to make sure that tmpfs has been mounted. Otherwise,
> the boot log will still be missing.
> ...
> case "$ACTION" in
> start)
> + mount -a -t tmpfs 2>/dev/null
This will mount filesystems out-of-order. E.g. it will break an /etc/fstab
with
| /dev/mm
Richard Purdie
writes:
> The list of things we assume are ok is relatively small and we look at
> new issues on a case by case basis. I think sed is well enough
> established and well enough behaved to be something we can rely on. In
> general we don't rely on much. Do you have any other specific
Rongqing Li
writes:
ConditionKernelCommandLine!=root=/dev/nfs
>>
>>> >
>>> >What is your meaning?
>> That's you are creating a huge script that does something built into systemd.
>>
>
>
> Yes, I can not find a way to avoid to that,
>
> Do you have any advice?
I would split the cmdline
Rongqing Li writes:
>>> Do you have any advice?
>>
>> I would split the cmdline generation into a dedicated one-shot service;
>> e.g. modify the original connman.service to have something like
> ...
> I test your method, but failed to start connmand,
> it always report "hand over timeout", I thin
writes:
> +/usr/sbin/connmand -n $EXTRA_PARAM
this must be 'exec /usr/sbin/connmand'; else you keep an unneeded 'sh'
process around.
Enrico
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mai
1 - 100 of 389 matches
Mail list logo
