Re: [OE-core] [PATCH 1/1] libsolve: 0001-Add-fallback-fopencookie-implementation.patch fix attribution

On 4/10/17 4:29 PM, Khem Raj wrote: > > > On 4/10/17 1:58 PM, Mark Hatle wrote: >> This patch has no technical change, but attempts to properly restore the >> attribution of the original patch to Neal Gompa. >> > > I think it will be good to add some guidelines

[OE-core] [PATCH 1/1] libsolve: 0001-Add-fallback-fopencookie-implementation.patch fix attribution

This patch has no technical change, but attempts to properly restore the attribution of the original patch to Neal Gompa. Signed-off-by: Mark Hatle --- ...1-Add-fallback-fopencookie-implementation.patch | 186 + 1 file changed, 150 insertions(+), 36 deletions(-) diff --git

[OE-core] [PATCH 0/1] Restore proper attributions to libsolv patch

ress permission.) Mark Hatle (1): libsolve: 0001-Add-fallback-fopencookie-implementation.patch fix attribution ...1-Add-fallback-fopencookie-implementation.patch | 186 + 1 file changed, 150 insertions(+), 36 deletions

[OE-core] Fwd: About misappropriation of one of my patches in OpenEmbedded

2017 16:13:57 -0400 From: Neal Gompa To: openembedded-core@lists.openembedded.org CC: richard.pur...@linuxfoundation.org, Mark Hatle Hello all, Recently, I started poking around with Yocto/OE stuff (specifically around the RPM stack) and I noticed that one of my patches was pulled into

[OE-core] scripts/rpm2cpio.sh -- master version

The change to the rpm4 version of rpm2cpio.sh has triggered a problem on a few of our older build machines. Specifically: dd: invalid input flag: `skip_bytes' Try `dd --help' for more information. I was doing some investigation, and the line causing the issue is: dd if="$pkg" skip="$o" ifla

[OE-core] [PATCH 3/4] compatlayer/__init__.py: Allow add_layer to process recursive deps

D are all dependencies of LayerA. Signed-off-by: Mark Hatle --- scripts/lib/compatlayer/__init__.py | 40 - 1 file changed, 35 insertions(+), 5 deletions(-) diff --git a/scripts/lib/compatlayer/__init__.py b/scripts/lib/compatlayer/__init__.py index 58

[OE-core] [PATCH 2/4] yocto-compat-layer.py: Add --dependency argument

When processing a large number of items, there are times that it would be nice to be able to pass in a series of layers that can be used as dependencies for the layer that is being scanned. This avoids the significant overhead of processing all of the layers to compatibility. Signed-off-by: Mark

[OE-core] [PATCH 4/4] yocto-compat-layer.py: Fix the signature validation

process the dependencies first, and then add the layer itself for the comparison. Signed-off-by: Mark Hatle --- scripts/lib/compatlayer/__init__.py | 7 --- scripts/yocto-compat-layer.py | 29 +++-- 2 files changed, 23 insertions(+), 13 deletions(-) diff --git a

[OE-core] [PATCH 1/4] yocto-compat-layer.py: Add status for skipped items

If items were skipped because the dependencies could not be found, we want to record this was skipped so we can display it later. Signed-off-by: Mark Hatle --- scripts/yocto-compat-layer.py | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/scripts/yocto-compat

[OE-core] [PATCH 0/4] yocto-compat-layer.py updates

were calculated), causing the dependencies for a BSP layer to trigger a failure in signature validation. Mark Hatle (4): yocto-compat-layer.py: Add status for skipped items yocto-compat-layer.py: Add --dependency argument compatlayer/__init__.py: Allow add_layer to process recursive deps

Re: [OE-core] [PATCH] bitbake.conf: add whoami to HOSTTOOLS

On 3/29/17 4:09 PM, Andreas Oberritter wrote: > On Wed, 29 Mar 2017 22:45:17 +0200 > Andrea Adami wrote: > >> Spotted in log do_compile of linux: >> >> /tmp/build/tmp-glibc/work-shared/c7x0/kernel-source/scripts/mkcompile_h: >> line 46: whoami: command not found > > As an alternative, we could

Re: [OE-core] [PATCH] bitbake.conf: add whoami to HOSTTOOLS

On 3/29/17 3:45 PM, Andrea Adami wrote: > Spotted in log do_compile of linux: > > /tmp/build/tmp-glibc/work-shared/c7x0/kernel-source/scripts/mkcompile_h: > line 46: whoami: command not found We should not be embedding 'whoami' type information into compiled executables. I'd almost suggest thi

Re: [OE-core] possible content for site.conf?

On 3/22/17 7:02 PM, Robert P. J. Day wrote: > On Wed, 22 Mar 2017, Burton, Ross wrote: > >> >> On 22 March 2017 at 10:51, Robert P. J. Day wrote: >> from site.conf.sample, the obvious content is things like: >> >> * download dir >> * reference to local (in-house) source mirror

Re: [OE-core] [PATCHv2 2/2] useradd-staticids.bbclass: Always fail/warn for missing IDs

On 3/14/17 10:56 AM, Peter Kjellerstedt wrote: > Previously, with USERADD_ERROR_DYNAMIC set to error/warn, if a static > UID/GID was specified in the recipe, then no error/warning would be > issued even if no ID was specified in the passwd/groups files. I'm glad it was this simple to implement. A

Re: [OE-core] [PATCHv2 1/2] useradd-staticids.bbclass: Support recipes specifying static IDs

On 3/14/17 10:56 AM, Peter Kjellerstedt wrote: > If this bblcass is used and a recipe specifies a static ID for a 'bbclass' (typo) Otherwise, acked. > user/group as part of the USERADD_PARAM_${PN} or GROUPADD_PARAM_${PN}, > the build would fail with and error like this if there was no > corresp

Re: [OE-core] [PATCH] useradd-staticids.bbclass: Support recipes specifying static IDs

On 3/13/17 7:47 PM, Peter Kjellerstedt wrote: >> -Original Message- >> From: Mark Hatle [mailto:mark.ha...@windriver.com] >> Sent: den 13 mars 2017 17:50 >> To: Peter Kjellerstedt; openembedded-core@lists.openembedded.org >> Subject: Re: [OE-core] [PATCH] user

Re: [OE-core] [PATCH] useradd-staticids.bbclass: Support recipes specifying static IDs

On 3/13/17 11:11 AM, Peter Kjellerstedt wrote: >> -Original Message- >> From: Mark Hatle [mailto:mark.ha...@windriver.com] >> Sent: den 13 mars 2017 14:56 >> To: Peter Kjellerstedt; openembedded-core@lists.openembedded.org >> Subject: Re: [OE-core] [PA

Re: [OE-core] [PATCH 36/44] package_rpm.bbclass: do not set the OS dynamically when building rpms

On 3/13/17 9:24 AM, Alexander Kanavin wrote: > On 03/10/2017 06:57 PM, Mark Hatle wrote: >> On 3/10/17 5:24 AM, Alexander Kanavin wrote: >>> Packages need to contain just one value for the os field, otherwise >>> rpm will refuse to install them if they don't match

Re: [OE-core] [PATCH 34/44] package_rpm.bbclass: add a /bin/sh Provides for nativesdk- packages

On 3/13/17 9:21 AM, Alexander Kanavin wrote: > On 03/10/2017 06:54 PM, Mark Hatle wrote: >> On 3/10/17 5:24 AM, Alexander Kanavin wrote: >>> nativesdk-* rpm packages all require /bin/sh because postinst scriptlets >>> are run with it. We can either teach rpm4 and dn

Re: [OE-core] [PATCH 30/44] byacc: remove the recipe

On 3/13/17 8:18 AM, Alexander Kanavin wrote: > On 03/10/2017 06:37 PM, Mark Hatle wrote: >> byacc, until recently, was required by the LSB / LSB Test Suite. >> >> So I'd rather is be kept in oe-core through the 2.3 release. > > I couldn't find it in the

Re: [OE-core] how does files/fs-perms.txt affect building base-files rpm?

On 3/11/17 3:57 AM, Robert P. J. Day wrote: > On Sat, 11 Mar 2017, Khem Raj wrote: > >> On 3/11/17 12:30 AM, Robert P. J. Day wrote: >>> >>> potentially a dumb question, but do the settings in >>> files/fs-perms.txt affect the building of the base-files rpm just >>> as they would affect the buil

Re: [OE-core] [PATCH] useradd-staticids.bbclass: Support recipes specifying static IDs

On 3/10/17 11:27 PM, Peter Kjellerstedt wrote: > If this bblcass is used and a recipe specifies a static ID for a > user/group as part of the USERADD_PARAM_${PN} or GROUPADD_PARAM_${PN}, > the build would fail with and error like this if there was no > corresponding ID in the passwd/group files spe

Re: [OE-core] [PATCH 22/44] scripts/rpm2cpio.sh: replace 5.x version with 4.x version

Just an FYI, I was concerned that $(( )) (in the new script) was a bash-ism, but I was able to run the script on an Ubuntu machine using 'dash' as /bin/sh. --Mark On 3/10/17 5:24 AM, Alexander Kanavin wrote: > Signed-off-by: Alexander Kanavin > --- > scripts/rpm2cpio.sh | 108 > ++

Re: [OE-core] [PATCH 41/44] bash: package bashbug separately

On 3/10/17 5:24 AM, Alexander Kanavin wrote: > It's a machine-specific script, which is causing conflicts > when multiple versions of bash are installed in multilib setting, > and it also does not really make sense for embedded systems anyway. Out of curiosity what is machine specific here? (The

Re: [OE-core] [PATCH 39/44] package.bbclass: don't exclude package groups from runtime mapping

On 3/10/17 5:24 AM, Alexander Kanavin wrote: > This ensures that remapping happens correctly, particularly > when package groups list noarch packages, and multilib is in use. Previously > this was masked by rpm doing *another* layer of remapping on top of this. This change is definitely NOT rpm sp

Re: [OE-core] [PATCH 38/44] package_rpm.bbclass: do not strip multilib prefixes from package names, do not add multilib prefix to package arch

On 3/10/17 5:24 AM, Alexander Kanavin wrote: > This is done for reasons I cannot establish, and greatly complicates the code > that installs packages into rootfs. RPM internally resolves ELF dependencies through a resolution system. If you look at a typical Fedora, SuSe, etc system you will often

Re: [OE-core] [PATCH 36/44] package_rpm.bbclass: do not set the OS dynamically when building rpms

On 3/10/17 5:24 AM, Alexander Kanavin wrote: > Packages need to contain just one value for the os field, otherwise > rpm will refuse to install them if they don't match what is in > /etc/rpm/platform. How will this work with nativesdk for things like targeting mingw (windows), darwin, or even alte

Re: [OE-core] [PATCH 34/44] package_rpm.bbclass: add a /bin/sh Provides for nativesdk- packages

On 3/10/17 5:24 AM, Alexander Kanavin wrote: > nativesdk-* rpm packages all require /bin/sh because postinst scriptlets > are run with it. We can either teach rpm4 and dnf to ignore that dependency > (a lot of non-upstreamable work), or add auto-satisfy the dependency > in each package. I've chosen

Re: [OE-core] [PATCH 19/44] package_rpm.bbclass: correctly map RRECOMMENDS and RSUGGESTS to rpm tags

On 3/10/17 5:23 AM, Alexander Kanavin wrote: > Previously they were swapped, not sure why. Their meaning, as far as rpm > world goes, is different: Just an FYI -- In RPM5 (well before rpm4 had support for recommended packages) it was implemented as 'suggests'. I have no idea why. --Mark > - Rec

Re: [OE-core] [PATCH 30/44] byacc: remove the recipe

byacc, until recently, was required by the LSB / LSB Test Suite. So I'd rather is be kept in oe-core through the 2.3 release. --Mark On 3/10/17 5:24 AM, Alexander Kanavin wrote: > It was used only by rpm5 and will be moved to meta-oe > > Signed-off-by: Alexander Kanavin > --- > meta/recipes-e

[OE-core] gpgme -- yet another python issue...

I don't have a fix for this, but if I enable multilib processing I see two additional issues. Maybe someone else can spot how to fix this? My config (add to local.conf) # Uncomment the following lines to enable multilib builds require conf/multilib.conf MULTILIBS = "multilib:lib32" DEFAULTTUNE_v

Re: [OE-core] [PATCH] classes: add gitupstream class

On 3/8/17 11:45 AM, Burton, Ross wrote: > > On 8 March 2017 at 17:43, Mark Hatle <mailto:mark.ha...@windriver.com>> wrote: > > Devtool can do something similar, create a custom recipe... but I don't > believe > it has the ability to take an existing (pa

Re: [OE-core] [PATCH] openssl: disable cryptodev by default

On 3/8/17 11:35 AM, Richard Purdie wrote: > On Wed, 2017-03-08 at 11:28 -0600, Mark Hatle wrote: >> On 3/8/17 10:57 AM, Ross Burton wrote: >>> >>> Cryptodev is a way for userspace to access the kernel crypto >>> drivers (and so, >>> hardware crypto). &g

Re: [OE-core] [PATCH] classes: add gitupstream class

On 3/8/17 11:36 AM, Burton, Ross wrote: > > On 8 March 2017 at 17:31, Mark Hatle <mailto:mark.ha...@windriver.com>> wrote: > > One of the uses I've seen people ask for is to take the (patched) > versions that > OE puts together, store these in their o

Re: [OE-core] [PATCH] classes: add gitupstream class

One of the uses I've seen people ask for is to take the (patched) versions that OE puts together, store these in their own git trees and manage it there -- also allowing them to patch them directly in their own trees. It appears to me this could be used to pull down that content. Have you thought

Re: [OE-core] [PATCH] openssl: disable cryptodev by default

On 3/8/17 10:57 AM, Ross Burton wrote: > Cryptodev is a way for userspace to access the kernel crypto drivers (and so, > hardware crypto). If the BSP does not support crypto dev, what is the harm in this? It should fall back to standard behaviors. > Not all hardware supports cryptodev so this is

Re: [OE-core] [PATCHv3 0/5] Add dummy tools to help identify needed dependencies

On 3/8/17 11:21 AM, Burton, Ross wrote: > > On 8 March 2017 at 09:43, Peter Kjellerstedt > wrote: > > since I see that you have integrated/staged the two patches that add > inherits of pkgconfig, but not the patches that add the dummy commands, > I

[OE-core] [PATCH v2] gpgme: Fix issue building for the target

anywhere. Define this. When building the python module, we can not call gpg-error-config, so we need to find an alternative way of finding the information the setup.py.in requires. (In this case, it's easy to just use the environment STAGING_INCDIR.) Signed-off-by: Mark Hatle --- .../

[OE-core] [PATCH v2] Fix gpgme when building for the target

: * PKG_CONFIG (pkg-config) was not being set * Auto selecting python would pick up the host version and fail * calling gpg-error-config would fail Mark Hatle (1): gpgme: Fix issue building for the target .../gpgme/gpgme/python-lang-config.patch | 52 ++ meta/recipes-support

Re: [OE-core] [PATCH] gpgme: Fix issue building for the target

On 3/7/17 10:08 AM, Burton, Ross wrote: > > On 7 March 2017 at 16:00, Mark Hatle <mailto:mark.ha...@windriver.com>> wrote: > > gpgme failed when configuring since you can only configure for one python > system at a time (via the inherits). So we need to have a

[OE-core] [PATCH] Fix gpgme when building for the target

Fix gpgme when building for the target. There were multiple problems when cross compiling gpgme for the target: * PKG_CONFIG (pkg-config) was not being set * Auto selecting python would pick up the host version and fail * calling gpg-error-config would fail Mark Hatle (1): gpgme: Fix issue

[OE-core] [PATCH] gpgme: Fix issue building for the target

anywhere. Define this. When building the python module, we can not call gpg-error-config, so we need to find an alternative way of finding the information the setup.py.in requires. (In this case, it's easy to just use the environment STAGING_INCDIR.) Signed-off-by: Mark Hatle --- .../

Re: [OE-core] [Openembedded-architecture] [PATCH] meta: start to ignore the largefile distro feature

On 3/7/17 4:35 AM, Burton, Ross wrote: > CCing openembedded-architecture to open the field for comments. At this point, I'm not sure there is any reason to NOT using largefile system wide. It's a common enough feature, and even 'small' devices (with sdcard slots) can run into large file problems

Re: [OE-core] something seems to have happened to "gpgme" in latest oe-core

FYI, I'm experiencing the same issue on master. --Mark On 2/20/17 11:40 AM, Burton, Ross wrote: > > On 20 February 2017 at 11:54, Robert P. J. Day > wrote: >> gpgme config.log attached. > > cc1: warning: include location "/usr/include/python2.7" is unsafe for >

[OE-core] [PATCH] Revert "flex: upgrade to 2.6.2"

n a header, but were not defined in the resulting generated code. The snippet above was from libsepol-native from the meta-selinux layer. The build was performed on a Fedora 24 system. Reverting that commit resolves the problem. Signed-off-by: Mark Hatle --- ...oid-c-comments-in-c-code-fails-wi

Re: [OE-core] [oe] OEDAM - Portland 2017

On 2/19/17 4:12 AM, Trevor Woerner wrote: > Does anyone have any recommendations for how to get from the > conference venue to the Mentor Graphics office? > I have a rental car and will have room for 2, or MAYBE 3 people. (At this point I suspect I will return the car after the OEDAM, because pa

Re: [OE-core] Want to strip rootfs

On 2/3/17 6:25 AM, ANDANI PRASHANT wrote: > Hi, > > I build rootfs which size is 100MB+ > As i look in to filesystem, there are 14mb libc-2.23.so , > 12mb libstdc++.so.6.0.22,..etc. > Is there any flag or option during build to strip all library and binary to > optimise size o

Re: [OE-core] do_populate_sysroot: Function failed: relocatable_binaries_preprocess

On 1/23/17 10:44 AM, Paul Gortmaker wrote: > 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

Re: [OE-core] [PATCH] sanity.bbclass: Improved error message

On 1/12/17 6:36 PM, Paul Eggleton wrote: > On Thu, 12 Jan 2017 16:04:09 Mark Hatle wrote: >> On 1/12/17 3:42 PM, Richard Purdie wrote: >>> On Thu, 2017-01-12 at 11:24 -0800, Juro Bystricky wrote: >>>> When a non-existing MACHINE is specified, sanity check issues &

Re: [OE-core] [PATCH] sanity.bbclass: Improved error message

On 1/12/17 3:42 PM, Richard Purdie wrote: > On Thu, 2017-01-12 at 11:24 -0800, Juro Bystricky wrote: >> When a non-existing MACHINE is specified, sanity check issues >> the following message: >> >> Please set a valid MACHINE in your local.conf or environment >> >> However, MACHINE can also be s

Re: [OE-core] [Openembedded-architecture] Deprecating hddimg/isoimg

On 12/20/16 2:23 PM, Saul Wold wrote: > > Folks, > > For years we have wanted to get rid of the hddimg/iso type, we now have > the WIC tool integrated into OE-Core such that we can build properly > partitioned disk images. No objection to getting rid of them, but I would love to see them replace

[OE-core] [master][morty][PATCH v2] glibc: Enable backtrace from abort on ARM

(__default_sa_restorer+0) [0x4befe1e0] /lib/libc.so.6(gsignal+0xa0) [0x4befcf74] /lib/libc.so.6(abort+0x134) [0x4befe358] ./test-app(dummy_function+0x50) [0x10adc] ./test-app(main+0xd4) [0x10c24] /lib/libc.so.6(__libc_start_main+0x114) [0x4bee7a58] Signed-off-by: Yuanjie Huang Signed-off-by: Mark Hatle

Re: [OE-core] [PATCH] glibc: Enable backtrace from abort on ARM

On 12/9/16 12:48 AM, Khem Raj wrote: > On Thu, Dec 8, 2016 at 11:03 AM, Mark Hatle wrote: >> +do_configure_append_arm () { >> + echo "CFLAGS-abort.c = -funwind-tables" >> ${B}/configparms >> + echo "CFLAGS-raise.c = -funwind-tables&quo

Re: [OE-core] [morty] [PATCH] glibc: Enable backtrace from abort on ARM

Forgot to mention, also applicable to Morty. --Mark On 12/8/16 1:03 PM, Mark Hatle wrote: > From: Yuanjie Huang > > ARM stack frames for abort and raise were limited to the the actual > abort and raise call, such as: > > Obtained 4 stack frames. > ./test-app(print

[OE-core] [PATCH] glibc: Enable backtrace from abort on ARM

(__default_sa_restorer+0) [0x4befe1e0] /lib/libc.so.6(gsignal+0xa0) [0x4befcf74] /lib/libc.so.6(abort+0x134) [0x4befe358] ./test-app(dummy_function+0x50) [0x10adc] ./test-app(main+0xd4) [0x10c24] /lib/libc.so.6(__libc_start_main+0x114) [0x4bee7a58] Signed-off-by: Yuanjie Huang Signed-off-by: Mark Hatle

Re: [OE-core] [Openembedded-architecture] RFC BuildAppliance future

On 12/5/16 12:04 PM, Brian Avery wrote: > Please note, this is going out to 3 lists in an attempt to insure that no > one > who would be impacted by this change misses it. Implied spam apology included. > > The Yocto Project currently provides a virtual machine image called the > Build > App

Re: [OE-core] [PATCH v3] rootfs: Modify RPM installation

On 11/25/16 12:17 PM, Burton, Ross wrote: > > On 24 November 2016 at 10:49, David Vincent > wrote: > > -self._setup_dbg_rootfs(['/etc/rpm', '/var/lib/rpm', > '/var/lib/smart']) > +self._setup_dbg_rootfs(['/etc/rpm', rpm_libdir, > '/var/lib/

Re: [OE-core] [PATCH] meta/conf/layer.conf: Add recommended download layer

On 11/23/16 7:16 PM, Christopher Larson wrote: > On Wed, Nov 23, 2016 at 12:42 PM, Mark Hatle <mailto:mark.ha...@windriver.com>> wrote: > > On 11/23/16 12:56 PM, Martin Jansa wrote: > > On Wed, Nov 23, 2016 at 12:38:42PM -0600, Mark Hatle wrote: > >

Re: [OE-core] [PATCH] meta/conf/layer.conf: Add recommended download layer

On 11/23/16 12:56 PM, Martin Jansa wrote: > On Wed, Nov 23, 2016 at 12:38:42PM -0600, Mark Hatle wrote: >> On 11/23/16 12:10 PM, Martin Jansa wrote: >>> On Wed, Nov 23, 2016 at 11:42:09AM -0600, Mark Hatle wrote: >>>> This is a Wind River specific patch and not gene

Re: [OE-core] [PATCH] meta/conf/layer.conf: Add recommended download layer

On 11/23/16 12:10 PM, Martin Jansa wrote: > On Wed, Nov 23, 2016 at 11:42:09AM -0600, Mark Hatle wrote: >> This is a Wind River specific patch and not generally applicable. > > Then why is it sent to oe-core ML? As noted in the cover letter, I'm required to by Yoct

[OE-core] [PATCH] meta/conf/layer.conf: Add recommended download layer

This is a Wind River specific patch and not generally applicable. Signed-off-by: Mark Hatle --- meta/conf/layer.conf | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf index 24b4df0..a94e524 100644 --- a/meta/conf/layer.conf +++ b/meta/conf

[OE-core] [PATCH] Add recommended layer to oe-core

yer. The layer recommends allows us to optionally depend on these special layers. Mark Hatle (1): meta/conf/layer.conf: Add recommended download layer meta/conf/layer.conf | 2 ++ 1 file changed, 2 insertions(+) -- 2.9.3 -- ___ Openembedded-co

Re: [OE-core] [Openembedded-architecture] Enabling uninative by default in oe-core?

On 11/17/16 12:31 PM, Burton, Ross wrote: > Hi, > > Background: uninative is a class that downloads a precompiled host glibc for > use > in the sysroot, thus isolating the native sysroot from the host environment. > This means greater sstate reuse, as instead of native builds being dependent >

Re: [OE-core] WRL error: "Can't locate Config_heavy-target.pl in @INC" -- OE versus WRL

On 11/13/16 4:49 AM, Robert P. J. Day wrote: > > sorry, i'm still confused, let me make sure i understand this ... > > On Sat, 12 Nov 2016, Mark Hatle wrote: > >> On 11/12/16 2:45 PM, Robert P. J. Day wrote: >>> >>> (note: this is actually an er

Re: [OE-core] WRL error: "Can't locate Config_heavy-target.pl in @INC" -- OE versus WRL

On 11/12/16 2:45 PM, Robert P. J. Day wrote: > > (note: this is actually an error i'm getting under wind river linux > 8, i'm just curious as to why OE works just fine.) > > as mentioned, when trying to build a trivial hand-rolled perl recipe > under wind river linux 8, i'm getting: > > | Ca

Re: [OE-core] [OE-Core][Patch 00/13] MIPS: Use MACHINEOVERRIDES and reduce duplication

I've looked over the set, it all looks reasonable to me. Acked-by: Mark Hatle --Mark On 11/7/16 9:01 AM, Zubair Lutfullah Kakakhel wrote: > Hi, > > This patch series adds a few MACHINEOVERRIDES options in arch-mips > to reduce duplicate configurations in various recipes. >

Re: [OE-core] [PATCH] db: disable the ARM assembler mutex code

On 11/4/16 11:12 AM, Leonardo Sandoval wrote: > This patch cannot be applied because the modified file is not track by > oe-core. > The original submitted should have mentioned this patch is against Jethro. However the patch is directly applicable to master, morty and korgoth as well. Li, pleas

Re: [OE-core] version of gdb in morty

On 11/3/16 9:06 AM, Burton, Ross wrote: > > On 3 November 2016 at 13:32, Alexander Kanavin > mailto:alexander.kana...@linux.intel.com>> > wrote: > > Update to 7.12 for master branch please. > > > To ease backporting to morty, taking 7.11.1 and then 7.12 makes sense to me. I'm fine with thi

Re: [OE-core] [PATCH] glibc: Fix timestamp of plural.c after unpack

On 10/11/16 1:53 PM, Phil Blundell wrote: > On Tue, 2016-10-11 at 16:02 +0800, Yuanjie Huang wrote: >> From: Yuanjie Huang >> >> Source file plural.c might be updated with bison from plural.y, touch >> it >> before applying patches so that this file is consistent across >> builds. > > I think it

Re: [OE-core] [PATCH] glibc: Fix timestamp of plural.c after unpack

On 10/11/16 11:46 AM, Gary Thomas wrote: > On 2016-10-11 11:22, Enrico Scholz wrote: >> Mark Hatle writes: >> >>> My understanding of the issue is that the extraction of the plural.c and >>> plural.y files happens so quickly that it is unclear to make if one is

Re: [OE-core] [PATCH] glibc: Fix timestamp of plural.c after unpack

c file as shipped by glibc. It has the possibility of introducing problems but the immediate concern is the non-determinism where some builds rebuild, some do not. --Mark > Yuanjie > > On 10/11/2016 05:17 PM, Burton, Ross wrote: >> >> On 11 October 2016 at 09:37

Re: [OE-core] [PATCH] glibc: Fix timestamp of plural.c after unpack

FYI this particular issue was observed by one of our customers. Starting around the YP 2.0 time period. (We did not observe the problem prior to 2.0, but it may be present.) My understanding of the issue is that the extraction of the plural.c and plural.y files happens so quickly that it is uncl

[OE-core] [PATCH v2] Fix linuxloader reference for MIPS*

v2: Fixed spacing (accidently used spaces and NOT tabs) Fix linux loader reference for MIPS* Note, this patch assumes the previously submitted change for the mipsisa*r6* work has been applied. It's critical that the mips* match is -after- any more specific mips matches. Mark Hat

[OE-core] [PATCH v2] linuxloader.bbclass: Adjust mips to cover all mips/mips64

: Mark Hatle --- meta/classes/linuxloader.bbclass | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/meta/classes/linuxloader.bbclass b/meta/classes/linuxloader.bbclass index 8d85e6e..117b030 100644 --- a/meta/classes/linuxloader.bbclass +++ b/meta/classes/linuxloader.bbclass

[OE-core] [PATCH] linuxloader.bbclass: Adjust mips to cover all mips/mips64

: Mark Hatle --- meta/classes/linuxloader.bbclass | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/meta/classes/linuxloader.bbclass b/meta/classes/linuxloader.bbclass index 8d85e6e..4be5503 100644 --- a/meta/classes/linuxloader.bbclass +++ b/meta/classes/linuxloader.bbclass

[OE-core] [PATCH] Fix linuxloader reference for MIPS*

Fix linux loader reference for MIPS* Note, this patch assumes the previously submitted change for the mipsisa*r6* work has been applied. It's critical that the mips* match is -after- any more specific mips matches. Mark Hatle (1): linuxloader.bbclass: Adjust mips to cover all mips/m

Re: [OE-core] [OE-Core][PATCH 0/9] Add MIPS release 6 ISA support

A few general comments. I don't see an n32 variant implemented. I'd suggest a follow on patch (vs a new version) to add n32. It looks like it's missing in the files modified by patches 6-9. Otherwise I don't see any issues with adding the support for this new ISA. --Mark On 10/4/16 6:31 AM, Z

Re: [OE-core] openssl: OpenSSL 1.1.x update

On 10/6/16 10:22 AM, Khem Raj wrote: > >> On Oct 6, 2016, at 7:21 AM, Mark Hatle wrote: >> >> On 10/5/16 9:59 PM, Khem Raj wrote: >>> On Wed, Oct 5, 2016 at 7:33 PM, Mark Hatle wrote: >>>> On 10/5/16 9:11 PM, Tan, Raymond wrote: >>>>

Re: [OE-core] openssl: OpenSSL 1.1.x update

On 10/5/16 9:59 PM, Khem Raj wrote: > On Wed, Oct 5, 2016 at 7:33 PM, Mark Hatle wrote: >> On 10/5/16 9:11 PM, Tan, Raymond wrote: >>> Greetings, I would like to know if there is any plan / schedule to upgrade >>> to openssl 1.1.0 into OE-core? >> >> Curren

Re: [OE-core] openssl: OpenSSL 1.1.x update

On 10/5/16 9:11 PM, Tan, Raymond wrote: > Greetings, I would like to know if there is any plan / schedule to upgrade to > openssl 1.1.0 into OE-core? Currently 1.0.2 is the LTS version of OpenSSL. 1.1.0 is not scheduled to be LTS. For the upcoming release (soon), I would NOT expect 1.1.0 to b

Re: [OE-core] [bitbake-devel] Not building python socketmodule.c with openssl 1.0.2h

On 10/5/16 8:57 AM, Jeff Hatch wrote: > I am seeing an issue where we upgraded the openssl bitbake recipes to build > and > install openssl 1.0.2h in a higher layer than the base openembedded layer > which > was building openssl 1.0.1m. After this was done, the build of python 2.7.3 > stopped bu

Re: [OE-core] [PATCH] db: Upgrade to 6.0.35

On 9/28/16 10:44 AM, Alexander Kanavin wrote: > On 09/28/2016 06:44 PM, Mark Hatle wrote: >> On 9/28/16 10:26 AM, Khem Raj wrote: >>> We need to understand that disclaimer may be its requiring every one who is >>> distributing it to accept it. >> >> It is pu

Re: [OE-core] [PATCH] db: Upgrade to 6.0.35

On 9/28/16 10:26 AM, Khem Raj wrote: > We need to understand that disclaimer may be its requiring every one who is > distributing it to accept it. It is purely Oracle wanting to stop people from automatically downloading from them, also so they can harvest sales contacts. (nothing wrong with that

Re: [OE-core] [OE-Core][Patch v3] arch-mips: Add mips64r2 tunes

Acked, no concerns. --Mark On 9/23/16 8:47 AM, Zubair Lutfullah Kakakhel wrote: > Add MIPS64r2 optimizations > > Signed-off-by: Zubair Lutfullah Kakakhel > > --- > V2 -> V3 > Removed the unnecessary restructuring of the base tunings. > > V1 -> V2 > Fixed a subtle bug in the include files for

Re: [OE-core] [OE-Core][Patch] arch-mips: Add mips64-o32 tunes

Acked, no concerns. On 9/23/16 9:28 AM, Zubair Lutfullah Kakakhel wrote: > Add mips64 + o32 rootfs abi tune configurations > > Signed-off-by: Zubair Lutfullah Kakakhel > --- > meta/conf/machine/include/mips/arch-mips.inc | 26 ++ > 1 file changed, 26 insertions(+) > > d

[OE-core] [PATCH] pseudo: Fix problem where pseudo could kill a container init

docker mini-init to terminate. This doesn't happen in a traditional system, as systemd/sysvinit is protected to only root users can signal it. [YOCTO #10324] Signed-off-by: Mark Hatle --- .../files/0001-Don-t-send-SIGUSR1-to-init.patch| 48 ++ meta/recipes-devtools/p

Re: [OE-core] [PATCH 1/1] rpm: make install with --nosignature and --nodigest work

On 9/21/16 8:39 PM, Robert Yang wrote: > > > On 09/21/2016 10:10 PM, Mark Hatle wrote: >> On 9/20/16 10:37 PM, Robert Yang wrote: >>> >>> >>> On 09/21/2016 04:33 AM, Mark Hatle wrote: >>>> On 9/20/16 10:00 AM, Burton, Ross wrote:

Re: [OE-core] [PATCH 1/1] rpm: make install with --nosignature and --nodigest work

On 9/20/16 10:37 PM, Robert Yang wrote: > > > On 09/21/2016 04:33 AM, Mark Hatle wrote: >> On 9/20/16 10:00 AM, Burton, Ross wrote: >>> >>> On 20 September 2016 at 09:15, Hongxu Jia >> <mailto:hongxu@windriver.com>> wrote: >>> >>

Re: [OE-core] [PATCH 1/1] rpm: make install with --nosignature and --nodigest work

On 9/20/16 10:00 AM, Burton, Ross wrote: > > On 20 September 2016 at 09:15, Hongxu Jia > wrote: > > -Upstream-Status: Submitted [Sent email to rpm-de...@rpm5.org > ] > +Upstream-Status: Rejected [Sent email to rpm-de...@rpm5

Re: [OE-core] [OE-Core][Patch v2] arch-mips: Restructure mips64 and add mips64r2

On 9/20/16 9:07 AM, Zubair Lutfullah Kakakhel wrote: > Hi, > > On 09/20/2016 02:08 PM, Mark Hatle wrote: >> On 9/20/16 5:33 AM, Zubair Lutfullah Kakakhel wrote: >>> The current file structure felt slightly unsuitable for adding >>> MIPS64r2. So I restructur

Re: [OE-core] [OE-Core][Patch v2] arch-mips: Restructure mips64 and add mips64r2

On 9/20/16 5:33 AM, Zubair Lutfullah Kakakhel wrote: > The current file structure felt slightly unsuitable for adding > MIPS64r2. So I restructured it slightly and added MIPS64r2 > support > > Signed-off-by: Zubair Lutfullah Kakakhel > > --- > V1 -> V2 > Fixed a subtle bug in the include files f

[OE-core] [PATCH 1/2] package_manager.py: Adjust error message order

Move the debug before the error (as it can take many pages.) This makes it much easier for the user to see the actual error message as it is still on the screen. Signed-off-by: Mark Hatle --- meta/lib/oe/package_manager.py | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff

[OE-core] [PATCH 2/2] package_manager.py: Change diagnostic messages per IRC

Based on a discussion with IRC user: Ulfalizer It was suggested that removing the diagnostic list, and replacing it with a simple hint to what might be causing the problem was a better solution. Signed-off-by: Mark Hatle --- meta/lib/oe/package_manager.py | 20 1 file

Re: [OE-core] [PATCH 1/1] package_manager.py: fix bitbake package-index failed

FYI this is fixing Yocto Project defect 10258. --Mark On 9/13/16 3:48 AM, Hongxu Jia wrote: > Previously the following commit in oe-core move RPM metadata > from DEPLOY_DIR to WORKDIR. > --- > commit a92c196449c516fe51786d429078bbb1213bb029 > Author: Stephano Cetola > Date: Wed Aug 10

Re: [OE-core] [PATCH] rootfs.py: support absolute paths in IMAGE_DEVICE_TABLES

On 9/12/16 10:20 PM, Andre McCurdy wrote: > On Mon, Sep 12, 2016 at 5:17 PM, Mark Hatle wrote: >> On 9/12/16 6:00 PM, Andre McCurdy wrote: >>> Paths relative to BBPATH are fine if device table files are always >>> static and contained somewhere within a meta layer. H

Re: [OE-core] [PATCH] rootfs.py: support absolute paths in IMAGE_DEVICE_TABLES

On 9/12/16 6:00 PM, Andre McCurdy wrote: > Paths relative to BBPATH are fine if device table files are always > static and contained somewhere within a meta layer. However if device > tables are created dynamically, they will be located somewhere within > ${TMPDIR} and most conveniently referenced

Re: [OE-core] [PATCH] rpm: remove redundant removals

On 9/8/16 2:04 PM, Ross Burton wrote: > These were noticed by the use of bashisms (rm *.{foo,bar}) and lots of these > rm > commands are deleting files which don't exist in the first place. > > Signed-off-by: Ross Burton > --- > meta/recipes-devtools/rpm/rpm_5.4.16.bb | 45 > --

Re: [OE-core] [PATCH v2 2/3] oe.path: preserve xattr in copytree() and copyhardlinktree()

On 8/30/16 9:05 PM, Joshua Lock wrote: > Pass appropriate options to tar invocations in copytree() and > copyhardlinktree() to ensure that any extended attributes on the files > are preserved during the copy. > > We have to drop the use cpio in "Copy-pass" mode in copyhardlinktree() > because cpio

Re: [OE-core] [PATCH 1/1] gcc-runtime.inc: add CPP support for mips64-n32 tune

On 8/30/16 6:45 AM, Juro Bystricky wrote: > This patch fixes the problem where the CPP compiler cannot find include files. > The compiler is configured to look for the files in places that do not exist. > When querying the CPP for search paths, we observe messages such as these: > > multilib confi

Re: [OE-core] [PATCH 2/2] oe.path: preserve xattr in copytree() and copyhardlinktree()

On 8/26/16 10:43 AM, Joshua Lock wrote: > Pass appropriate options to tar invocations in copytree() and > copyhardlinktree() to ensure that any extended attributes on the files > are preserved during the copy. > > We have to drop the use cpio in "Copy-pass" mode in copyhardlinktree() > because cpi

<    1   2   3   4   5   6   7   8   9   10   >