Pushed, thanks.
On 23 April 2018 at 11:23, Peter Kjellerstedt
wrote:
> The man pages for this package was disabled in 46349e1a with the result
> that the following warnings appeared:
>
> WARNING: coreutils-6.9-r0 do_package: coreutils: alternative target
> (/usr/share/man/man1/su.1 or /usr/sh
Merged, thanks.
Ross
On 23 April 2018 at 11:56, Peter Kjellerstedt
wrote:
> Change-Id: I86ca76ca762da515fb6dfc95e2afd14cfe802fff
> Signed-off-by: Peter Kjellerstedt
> ---
> recipes-core/coreutils/coreutils-6.9/coreutils-overflow.patch | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
On 20 April 2018 at 11:47, Uwe Geuder wrote:
> But can you share state between distros? Isn't the purpose of distros to
> use different options (variable settings) so the state would always be
> different?
If the input to the recipe is different then the hashes would be
different so the content w
problems" can be found, and if they can be easily detected or not.
>
>
> Does some of you have any experience using a shared sstate cache?
>
>
>
>
>
> 2018-04-23 17:10 GMT+02:00 Burton, Ross :
>
>> On 20 April 2018 at 11:47, Uwe Geuder wrote:
>> >
On 24 April 2018 at 08:09, Nishina A. Pervin
wrote:
> When I am trying to import pexpect to make my program interactive in Krogoth
> branch of Yocto build for imx6qsabreauto board, i am getting the following
> error: Please help me to resolve the issue.
> root@imx6qsabreauto:/usr/bin# ./SensorTag.
Hi,
We have a build ready for QA for the Yocto Project release 2.5,
release candidate 1. As with the M3 this was built on the new
autobuilder so the announcement is happening manually again.
The release is available at:
http://autobuilder.yoctoproject.org/pub/releases/yocto-2.5.rc1/
The build
Plenty of recipes do that though...
On 25 April 2018 at 09:36, ChenQi wrote:
> I guess the problem is caused by the following line.
>
> S = "${WORKDIR}/"
>
> Try setting it to some dir under ${WORKDIR}, and make sure source file is
> under it.
> Check if the problem is still there after the above
Is the build tree deleted after it fails? It would be interesting to
see if the compiler is present in the sysroot, or if it has a
different name, or something else weird.
Do you have any global classes that do anything interesting/special?
Ross
On 25 April 2018 at 09:24, Mirza Krak wrote:
> H
ndirs] = "${@d.getVar('S') if d.getVar('S') !=
> d.getVar('WORKDIR') else os.path.join('${S}', 'patches')}"
>
> Best Regards,
> Chen Qi
>
>
> On 04/25/2018 04:38 PM, Burton, Ross wrote:
>>
>> Plenty of r
So my hunch is that you've a modern system with glibc 2.27 on the
host, so that old buildtools won't work. Try this buildtools:
http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-2.5_M3/buildtools/
Ross
On 24 April 2018 at 19:04, John Smith wrote:
> bitbake stops with this error
Hi,
Just thought I'd say that GCC 8 is going to start appearing in the
wild, I believe the first distro to ship with it will be Fedora 28.
As usual there are changes in behaviour so there are several problems.
So far I've identified the following issues:
* Python 2 crashes on startup
* Kernel too
On 25 April 2018 at 09:59, ChenQi wrote:
> After checking it again, I think removing the '/' would be sufficient.
>
> do_unpack[cleandirs] = "${@d.getVar('S') if d.getVar('S') !=
> d.getVar('WORKDIR') else os.path.join('${S}', 'patches')}"
To protect against this I'm running a test build with thi
On 25 April 2018 at 13:18, Uwe Geuder wrote:
> On Wed, Apr 25, 2018 at 1:48 PM, Burton, Ross wrote:
>> So my hunch is that you've a modern system with glibc 2.27 on the
>> host, so that old buildtools won't work. Try this buildtools:
>>
>> http://down
Hi Joshua,
I do now, they're in poky-contrib:ross/gcc8. The commit messages need
rewriting before merging to master.
Ross
On 25 April 2018 at 14:05, Joshua Watt wrote:
> On Wed, 2018-04-25 at 13:11 +0100, Burton, Ross wrote:
>> Hi,
>>
>> Just thought I'd s
That file is generated from your kernel's input.h, so I suspect this
is a problem with your kernel. If my hunch is right, building eudev
with MACHINE=qemux86 will work (and if that fails you've found a bug).
Ross
On 25 April 2018 at 16:04, Victor Palacio
wrote:
> Hello,
>
> Building a core-mini
Jethro doesn't support Yocto 16.* because it is very old (released
2015, it's been unmaintained for six months now). If you want to use
Jethro despite the known serious security problems then you'll need to
dig out the relevant fixes from the newer releases.
Ross
On 25 April 2018 at 20:36, Olive
Do you actually need pygtk, or the gobject-introspection bindings for
Python? The latter is what is supported upstream, traditional pygtk
was last released in 2011. If you're lucky you actually just need
gtk+3 and python-pygobject.
If you *really* need PyGTK then you'll have to resurrect the rec
The recipe specifies that Python 3 is to be used. If you want to
build it against Python 2 you'll have to patch the recipe.
Ross
On 28 April 2018 at 00:26, Russell Peterson wrote:
> I am trying to install libxml2 for python2 in my image recipe. Seems like it
> is being installed in the python
The make dependencies come from the ptest packages, so if you disable
ptest in your DISTRO_FEATURES then those should disappear.
Essentially doing a full build without any GPLv3 software *and* not
using old releases which are still GPLv2 is tricky. I can only
suggest you don't use the meta-gpl2 l
On 2 May 2018 at 01:41, Andre McCurdy wrote:
> On Tue, May 1, 2018 at 4:59 PM, Paul Eggleton
> wrote:
>> On Wednesday, 2 May 2018 11:54:00 AM NZST Andre McCurdy wrote:
>>> On Tue, May 1, 2018 at 3:10 PM, Paul Eggleton
>>> wrote:
>>> > On Wednesday, 2 Ma
On 2 May 2018 at 14:58, Alexander Kanavin wrote:
> On 05/02/2018 04:53 PM, Irving ST wrote:
>
>> Thank you for your help and explanations. Unfortunately just removing
>> ptest doesn't make it build.
>> This is the error when I tried bitbake core-image-minimal:
>>
>> ERROR: Nothing PROVIDES 'readl
On 1 May 2018 at 21:43, Raymond Yeung wrote:
> I'd just git cloned Rocko and meta-ti. When I try to source
> oe-init-build-env, I got errors:
>
>
> -bash: python3: command not found
>
> BitBake requires Python 3.4.0 or later as 'python3'. "python -V" gives
> "Python 2.7.9". "python3" is not in
I suggest you have a look through the feed that you link to and see if it
provides a package which has /usr/bin/python3 in, and if it doesn't then
just make a python3 -> python3.6 symlink (which is all you need).
Ross
On 2 May 2018 at 20:28, Raymond Yeung wrote:
> Thanks Zoran.
>
>
> My Linux b
On 10 May 2018 at 09:59, Piotr Piwko wrote:
>
>> VAR set in recipe A cannot be accessed by recipe B.
>>
>
> All right, but what about DISTRO_FEATURES? It is available everywhere, so
> maybe there is some possibility to do so ...
>
You need to think about what actually happens. This is a valid b
On 10 May 2018 at 01:40, Matt Hoosier wrote:
> On Wed, May 9, 2018 at 6:27 PM, Andre McCurdy wrote:
>>
>> On Wed, May 9, 2018 at 2:48 PM, Matt Hoosier
>> wrote:
>> > From: Matt Hoosier
>> >
>> > Although the submodules' histories have been fetched during the
>> > do_fetch() phase, the mechanics
Turns out this is due to uninative only having a limited subset of the
conversion tables and fontforge checks for ones that we don't ship.
The good news is that Khem sent a patch this morning, but the
workaround right now is to disable uninative. This in your local.conf
will work:
INHERIT_remove
I threw the branch at the Yocto Project autobuilder today, produced a
number of failures:
http://errors.yoctoproject.org/Errors/Latest//?filter=b23dba19607412c8cc7d267d95354d65f5631088&type=commit
Ross
On 5 May 2018 at 01:26, Khem Raj wrote:
> Hi All
>
> As you might have noticed that gcc 8.1 w
On 22 May 2018 at 08:43, Damien LEFEVRE wrote:
> I'm having to build a package (arrayfire) for Tegra. This package requires
> to first build a x86_64 utility (bin2cpp) which is then used for building
> the tegra arrayfire.
>
> Do I understand correctly that I should create:
>
> arrayfire-native.bb
On 22 May 2018 at 11:56, Damien LEFEVRE wrote:
> The recipe builds. When I try using with DEPENDS += "arrayfire-native" in
> the arrayfire recipe I get this warning:
> WARNING: arrayfire-3.6.0-r0 do_prepare_recipe_sysroot: Manifest
> /home/damien/pyro/build-jetson-tx2/tmp/sstate-control/manifest-
You want to pass -DSOME_MACRO to the compiler, so extend CPPFLAGS in
your recipe:
CPPFLAGS += "-DSOME_MACRO"
Note that this assumes the build system that the code is using is
listening to $CPPFLAGS.
Ross
On 29 May 2018 at 17:50, Ugesh Reddy wrote:
> Hello,
> I have the source code were the p
I've a nigh-on identical patch in master-next running on the AB already:
http://git.yoctoproject.org/cgit.cgi/meta-mingw/commit/?h=master-next&id=46b1bfd8ef26dd9c778504143d4dea2fbe2ce90f
Don't have the security flags bit though (our mingw builds don't use
that), can you rebase to master-next and
There's a grpc recipe in meta-oe:
http://layers.openembedded.org/layerindex/recipe/72419/
Ross
On 21 June 2018 at 19:15, Simon Chamlian wrote:
> Hi,
>
> I just started using Yocto.
>
> Is there a detailed procedure on how I can port gRPC (for C or C++) into a
> Yocto project?
>
> Thanks,
>
> S
>
AFAIK, you don't need the deptasks as the before/after statements will
insert the task in the right place.
Ross
On 25 June 2018 at 18:59, Måns Zigher wrote:
> Hi,
>
> I have created this simple class file
>
> python do_busybox_foo() {
> bb.warn("BUSYBOX: foo task!")
> }
> addtask busybox_foo
Just so you know, 2.3 is a year old. 2.5 is the latest release.
On 28 June 2018 at 06:59, Abhishek Kumar Rai
wrote:
> Hi Team,
>
> I am planning to use the LTP latest version on YOCTO latest vesion.
> It seems that the earlier YOCTO versions are released with LTP and
> latest version are not.
>
Hi Giordan,
https://wiki.yoctoproject.org/wiki/TipsAndTricks/Packaging_Prebuilt_Libraries
might be helpful to you.
One useful thing would be to show us exactly what files are being
installed (and what files are symlinks). It sounds like xrootd is
messing up library installation...
Ross
On 28 J
On 5 July 2018 at 08:26, Oliver Westermann wrote:
> I'm fiddeling around with yocto. I want to move some python stuff onto an
> embedded board and use the nxp mx8 yocto. Everything worked as expected
> until now, I was able to create yocto recipes for python modules like pyv4l2
> (is there any int
On 5 July 2018 at 15:49, Simon Chamlian wrote:
> After reading several documents, there seems to be several methods to
> add/remove packages from a build.
> I just want to make sure I am using the correct method that falls into YOCTO
> architecture.
>
> In local.conf file, I can use:
>
> IMAGE_INS
On 6 July 2018 at 13:32, Oliver Westermann wrote:
> This does not seem to work as expected. With option 1) and 2) it fails in
> do_compile:
>
> | DEBUG: Executing shell function do_compile
> |
> /data/workspace/yocto-build/build/mysys/tmp/work/aarch64-poky-linux/python3-pillow/5.2.0-r0/temp/run.d
So I tried this myself and it worked, which makes me thing your work
dir got messed up somehow. It's trying to build here but failing as
there are missing dependencies (no jpeg DEPENDS, for example).
Ross
On 6 July 2018 at 13:38, Burton, Ross wrote:
> On 6 July 2018 at 13:32, Oliver We
What. You've got inherit setuptools3 so it should be using our own
python3 and have setuptools present. This makes no sense. :/
Can you share the recipe you're building?
Ross
On 6 July 2018 at 13:56, Oliver Westermann wrote:
> Am Fr., 6. Juli 2018 um 14:38 Uhr schrieb
On 6 July 2018 at 14:06, Oliver Westermann wrote:
> Of course, thats the reason I'm here ;)
>
> SUMMARY = "Pillow (The friendly PIL fork)"
> HOMEPAGE = "http://python-pillow.org/";
> LICENSE = "EPLv1"
> LIC_FILES_CHKSUM = "file://LICENSE;md5=c6379001ecb47e2a0420c40177fc1125"
>
> SRC_URI[md5sum] =
badly
coded. Can you tell it where to look explicitly?
Ross
On 6 July 2018 at 14:53, Oliver Westermann wrote:
> Am Fr., 6. Juli 2018 um 15:13 Uhr schrieb Burton, Ross
> :
>>
>> Move your DEPENDS up, as the inherits are setting up DEPENDS with
>> python3-native python3-
The easiest thing would be to edit the installer script that goes into
the hddimg to create your extra partitions and whatever else you want
done.
Ross
On 6 July 2018 at 22:52, Raymond Yeung wrote:
> Is there any installer that I could download along with the .hddimg (or
> .iso) image to the RAM
Presumably you've a recipe for the vendor openssl. If it has the same
name but is a different version then just set PREFERRED_VERSION. If
it has a different name too, it should PROVIDE openssl and you can
just set PREFERRED_PROVIDER.
If it doesn't do either of those things, then it is broken.
R
hat would be the
> best.
>
>
> Raymond
>
>
> --
> *From:* Burton, Ross
> *Sent:* Saturday, July 7, 2018 3:41 PM
> *To:* Raymond Yeung
> *Cc:* yocto@yoctoproject.org
> *Subject:* Re: [yocto] How to remove openssl from sysroots
>
> Presumably you've a reci
cate where the logic is that generates this .hddimg file, perhaps I could
> figure out how it creates its single partition, and perhaps add one or more
> partitions to it as well.
>
>
> --
> *From:* Burton, Ross
> *Sent:* Saturday, July 7, 2018 3:39 PM
Some comments inline, including where I think your problem is:
On 9 July 2018 at 10:04, AKASH BHARDWAJ wrote:
> LICENSE = "CLOSED"
>>
>
Why are you setting LICENSE in local.conf?
> PACKAGE_FEED_URIS = " http://git.yoctoproject.org/cgit/cgit.cgi/meta-
>> raspberrypi/tree/recipes-devtools/wiring
If it's just a single simple binary that you need to run at build time
then you can build it manually in the target recipe before invoking
make.
The Pango recipe has an example of doing this.
Ross
On 7 July 2018 at 11:17, Alexander Kanavin wrote:
> How to do this is specific to each project. Ge
Hypothetically a new QA action should be added at the distro level, by
writing a class and adding it to INHERIT.
(I've several new QA tests added in this way)
Ross
On 10 July 2018 at 19:53, Alexander Kanavin wrote:
> Yes. Implement a class and inherit it from the recipes.
>
> Alex
>
> 2018-07-1
Using postgresql as an example, searching for it will take you to the
recipe page:
http://layers.openembedded.org/layerindex/recipe/5558/
This tells you that the recipe is in the meta-oe layer, so click on that:
http://layers.openembedded.org/layerindex/branch/master/layer/meta-oe/
That tells y
Does this also work for rocko and master if the bbappend used a
wildcard? Or is it not required for rocko and master?
Ross
On 11 July 2018 at 23:42, Juro Bystricky wrote:
> Build openssl.exe and several .dll files needed to run openssl
> under Windows
>
> Signed-off-by: Juro Bystricky
> ---
>
eta-networking/>
> (master branch)
>
>
> which one do I choose?
>
>
>
> On Thu, Jul 12, 2018 at 12:42 PM, Burton, Ross
> wrote:
>
>> Using postgresql as an example, searching for it will take you to the
>> recipe page:
>>
>> http://layers.openemb
> I'm wondering how I can make it so that I can have a user allow for
> additional configuration to enable crypto/krb5 which requires extra depends
> and changing the oemake flags. Is this something Yocto can do, or is it
> better to have users provide a bbappend file to update this recipe?
Yes, P
On 12 July 2018 at 23:12, Giordon Stark wrote:
> Hi Ross,
>
> Thanks. I saw that but the documentation doesn't explicitly mentioned
> EXTRA_OEMAKE. Is that the same as EXTRA_OECONF?
EXTRA_OEMAKE is what is passed to 'make' calls. Your recipe is using
cmake, so you're extending EXTRA_OECMAKE, whi
What recipe is failing? It's most likely to be a recipe which is
using a git tag instead of a git hash in the SRCREV.
Ross
On 13 July 2018 at 09:58, S, Karthikeyan wrote:
> Greetings,
>
> Initially I was able to built with github access, but our
> requirement is to build offline(wi
Isn't this the worst way of doing a microcode update? Specifically
the documentation for -k says:
"this update method is deprecated: it will be removed eventually
from the kernel and from iucode_tool.
Ross
On 16 July 2018 at 05:54, wrote:
> From: Changqing Li
>
> Add a service file (system
kernel recipe". Please find
> attached linux kernel bb files, all other remaining packages were built
> successfully.
>
> Thanks,
> Karthik
>
> -Original Message-
> From: Burton, Ross [mailto:ross.bur...@intel.com]
> Sent: Monday, July 16, 2018 2:57 PM
>
at 12:17, S, Karthikeyan wrote:
> Hi Ross,
> Sorry, I don’t have log file, I am attaching screenshot here and please
> let me know how to get log files
>
>
> Thanks & Regards,
> Karthik S
>
>
>
> -Original Message-
> From: Burton, Ross [mailto:ros
ositories";
> I may have to change something in SRC_URI and SRC_REV variable and this will
> work I guess, Please let me know what exactly I have to do. Thanks for
> supporting this issue.
>
> Thanks,
> Karthik
>
> -Original Message-
> From: Burton, Ross [ma
Read the configure log and it will tell you what went wrong, which may
or may not be easy to fix.
Ross
On 19 July 2018 at 22:01, Simon Chamlian wrote:
> Hi,
>
> Is there any recipe for the new snmp release 5.8 ?
>
> I took the net-snmp_5.7.3.bb file and renamed it net-snmp_5.8.bb
> removed the p
It shouldn't complain, what is the error? The reason it's being built
is because you've got X11 and Wayland enabled, so it's building
xwayland. When you add wayland to DISTRO_FEATURES, also remove x11.
Ross
On 21 July 2018 at 05:48, tugouxp <13824125...@163.com> wrote:
> hi folks:
> i am wo
It looks like you (or whoever maintains this glibc-dev branch you are
using) have upgraded curl yourself and didn't notice that curlbuild
doesn't exist in 7.57 onwards, so the oe_multilib_header call should
be removed.
(see oe-core 215d5677004537fc190b5381157ac8b94db6d7e8)
Ross
On 23 July 2018 a
Please remember to CC the list to that everyone can see.
On 23 July 2018 at 11:51, tugouxp <13824125...@163.com> wrote:
> hi burton:
> thanks for your answer. so how to dealt with this, seems two selection.
>
> 1. revert the version of curl
> 2. remove “oe_multilib_header”
>
> i am a fresh man
On 23 July 2018 at 12:21, tugouxp <13824125...@163.com> wrote:
> hi burton:
> sorry for that. :-|
>
> i still cant get what you said, forgive me for my foolish on that, can you
> show me how to do this? thanks for your kindly help.
Find the curl recipe, open it in an editor. They'll be a bloc
ter?
>
> thanks !
>
>
>
>
>
>
> At 2018-07-23 19:37:43, "Burton, Ross" wrote:
>>On 23 July 2018 at 12:21, tugouxp <13824125...@163.com> wrote:
>>> hi burton:
>>> sorry for that. :-|
>>>
>>> i still cant get
On 23 July 2018 at 18:30, Vikram Chhibber wrote:
> Thanks Mark. Is it possible to somehow use already created changelog while
> building rpm?
You mean that you'll maintain an independent changelog but want it to
be in the RPM?
Ross
--
___
yocto mailin
Yes, please do. Mohammad, as you can replicate this on demand, would
you be able to fix the unzip recipe with the patch in that bug and
send a patch?
Ross
On 23 July 2018 at 19:42, Andre McCurdy wrote:
> On Sat, Jul 21, 2018 at 12:55 AM, MOHAMMAD RASIM
> wrote:
>> well apparently this is cause
'grpc-native',
> 'gflags-native']
>
> Summary: There was 1 WARNING message shown.
> Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
> $
>
>
> There is no instructions on how we can compile this grpc into image?
>
> Thanks,
> S
> https://github.com/torvalds/linux/archive/master.zip use
> https://github.com/torvalds/linux/archive/master.tar.gz
>
>
> Thanks
>
>
>
> On 07/23/2018 09:51 PM, Burton, Ross wrote:
>>
>> Yes, please do. Mohammad, as you can replicate this on demand, would
>
On 27 July 2018 at 11:23, Ayoub Zaki wrote:
> The ERROR: lib32-my-image-1.0-r0 do_image_wic: The file
> /usr/share/gcc-7.3.0/python/libstdcxx/__init__.py is installed by both
> lib32-gcc-runtime and gcc-runtime, aborting is not self-explanatory!
>
> gcc-runtime is anyway not part of the image ?!
On 30 July 2018 at 14:28, Zoran Stojsavljevic
wrote:
> Anybody knows?
>
> Do all three exist in YOCTO as different libraries, or these are
> variations/the same as libconfig?
Context is useful but they all sound like various distribution names
for libconfig.
Ross
--
devtool add's primary convenience is how it can examine the source and
write the LICENSE correctly, the correct inherits, etc. If you're
just going to install a few files then just write a recipe from
scratch.
Ross
On 30 July 2018 at 15:10, Adam Lee wrote:
> Is it possible to run 'devtool add [
Obvious short answer is do you actually need to use the archiver in
patched mode? Changing to a different mode, or disabling the archiver
entirely, may solve this.
Long answer is this is most likely a race in the archiver, so filing a
bug with as many details as you can would be good.
Ross
On 3
Have a look at the archiver class.
Ross
On 7 August 2018 at 09:29, Fabien Lahoudere
wrote:
> Hello
>
> I need to extract all *GPL* sources patched related to an image in order to
> publish them.
> I want to do it automatically, ie 'bitbake myimage -c extract-gpl-sources'
> Is there a mechanism
patch.8027
> ERROR: Task (virtual:native:/home/aragua/src/poky/meta/recipes-
> support/gmp/gmp_6.1.2.bb:do_unpack_and_patch) failed with exit code '1'
>
> I tried to drop native from COPYLEFT_RECIPE_TYPES without effect.
>
> Where can I add quilt-native dependency?
>
> For informa
> Anyhow I would still like to report the bug. Are there any other ways
than using Bugzilla?
No, bugzilla is the only bug tracking system for oe-core.
Ross
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
The easy solution would be to not use meta-poky at all, but if you
insist then you'll have to set the layer priority so bitbake uses your
layer instead of meta-poky
Ross
On 9 August 2018 at 15:43, Yuvarajesh Valleru wrote:
> Hallo,
>
> I would like to overwrite the poky psplash splash screen [1]
That sounds like a bug but your fix isn't complete (doesn't handle
perl-native, for example), so the script should find the *-native
directories itself. I've filed
https://bugzilla.yoctoproject.org/show_bug.cgi?id=12889 so this
doesn't get lost.
Ross
On 10 August 2018 at 16:58, Aaron Cohen wrot
Why do you want to put it into /tmp? That's typically got a tmpfs mounted
on it at boot time so anything you put in there at rootfs time won't be
visible.
If you're goal is a read-write overlay on a read-only rootfs then look at
something like overlayfs.
Ross
On 13 August 2018 at 20:54, Bishop,
On 20 August 2018 at 01:33, bernardo araujo rodrigues
wrote:
> Looking at PhantomJS' github repo (https://github.com/ariya/phantomjs), I
> realized it's a PyBuild based project. However, I couldn't find any BitBake
> class like the setuptools or pypi that would support the build.py script.
That b
Please remember to CC the list.
On 28 August 2018 at 14:40, bernardo araujo rodrigues
wrote:
> Indeed I thought about calling "python3 build.py" inside the do_compile
> task.
>
> However my doubt is whether this will actually cross compile and integrate
> properly with the sysroot, or Python will
Was away for a week, back now. Merged to both master and sumo.
Thanks,
Ross
On 30 August 2018 at 15:12, Joshua Watt wrote:
>
>
> On Fri, Aug 24, 2018, 09:54 Joshua Watt wrote:
>>
>> Configures the mingw SDK environment to set the SWIG_LIB environment
>> variable so that swig can find its core
On 31 August 2018 at 11:57, Alexander Kanavin wrote:
> 2018-08-31 12:49 GMT+02:00 Alan Martinovic :
>> am just in the process of forming a base for automated nightly builds.
>> The goal is to have the build process run every night and report what
>> the status was.
>>
>> I've opted for python for
On 31 August 2018 at 12:24, Alan Martinovic wrote:
> Thanks Ross
> this is what more or less what I'm doing.
> What I haven't found a way to do from python is making modifications from
> the initialized build directory.
>
> I'd like to do that to change things in conf/local.conf.
> For example gen
On 31 August 2018 at 12:45, Alan Martinovic wrote:
> Fair enough, I gave an example with a simple workaround. :)
>
> But you do have a point there, if I'm getting you answer right on a broader
> level.
> Is it something like this?
>
>> Instead of setting the environment only once and running bitba
In a local.conf:
PTEST_ENABLE_pn-apparmor = "0"
(the overrides are prefixed with pn-)
In a bbappend just PTEST_ENABLE="0" will work.
Ross
On 31 August 2018 at 14:09, Mardegan, Alberto wrote:
> Hi there!
> the apparmor recipe from the meta-security layer fails to build in
> rocko due to an e
The autoconf-archive contents - by virtue of just being m4 scripts -
do not change per tune, so the allarch warning is irrelevant.
Ross
On 12 September 2018 at 14:15, Dudziak Krzysztof
wrote:
> Hi,
>
> myself grabbed autoconf-archive recipe from
>
> http://cgit.openembedded.org/openembedded-core
Re-adding yocto@ to CC.
On 13 September 2018 at 09:42, Dudziak Krzysztof
wrote:
> Myself does not address level of warnings. TBH I did not check how the
> warnings status is.
> Myself operates currently at recipe's level, no more.
> In lights of my understanding, which of course might still be w
On 13 September 2018 at 10:17, Dudziak Krzysztof
wrote:
> Is this rule’s scope literally each single recipe separately
>
> or rather the compound .bb file + set of matching .bbappends?
Compound.
> I am going to use that method for building autoconf-archive package
>
> as for device built here th
Adding yocto@ back to CC. Please remember to mail the list and not the sender.
On 13 September 2018 at 10:34, Dudziak Krzysztof
wrote:
> Will BBCLASSEXTEND=native fashion also build target system package?
> This is what is not needed (autoconf-archive on target system).
> Therefore thoughts turn
CCing the list again. Please remember to reply to the list.
On 13 September 2018 at 11:42, Dudziak Krzysztof
wrote:
> Is it possible for one Bitbake target to check list and order of classes
> inherited?
bitbake -e [recipe] will show you what was parsed.
In this situation I wouldn't worry too
On 13 September 2018 at 12:39, Dudziak Krzysztof
wrote:
> Thanks for hints.
> I don't want to have this package on target system.
> You sound like inheriting explicitly had some major drawback of wide scope.
It won't be included in the image unless you add it to the image.
Ross
--
_
On Mon, 17 Sep 2018 at 08:13, Peter Bergin wrote:
> I'm pretty sure I have narrowed down the root cause to the restriction
> of virtual memory and that liblzma base its memory calculations on
> physical RAM.
>
> To prove this I added a printout in rpm-native/rpmio/rpmio.c and the
> function lzopen
The problem is most likely that you're not using automake but the
generated recipe (would have been useful to include that) is using the
autotools class, which assumes correct use of both autoconf and
automake. Specifically, your hand-written Makefile doesn't handle
out-of-tree builds.
Change the
On Tue, 18 Sep 2018 at 22:21, Seebs wrote:
> > Are the databases supposed to be shareable between different build
> > machines? IIRC, the answer is no. Could you store the native inode
> > type as a sqlite BLOB? Not necessarily a good idea Just an idea.
>
> I think coercing the values into ran
Please remember to reply to the list.
On Wed, 19 Sep 2018 at 13:08, Mohamed Youseif
wrote:
> Thanks, Ross for replying, I had changed the recipe and tried to get the
> source code of ninvaders package from SourceForge with .tar extension,
> so the new recipe created was different than the old on
If you're targeting just x86 then you can build an image with the
tools-sdk IMAGE_FEATURE defined, and use something like systemd-nspawn
(insert your preferred container system) to get a shell in it.
Ross
On Wed, 19 Sep 2018 at 18:14, Fabian Sturm wrote:
>
> Hi,
>
> no this is not what I am searc
iles for the image packages
> tools-sdk: install the toolchain packages into the image
> IMAGE_INSTALL += "cmake": here I define any other development tool that
> I need in my image
>
> I this correct? At least it seems the created image contains everything
> I need!
>
On Thu, 20 Sep 2018 at 10:01, Mohamed Youseif
wrote:
> I had changed the source of my package, and create a new recipe for my
> package so it fetches from SourceForge, the new recipe does not inherit
> Autotools and modify the do_compile, do_install as following:
> do_compile () {
> oe_run
namically
> linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32,
> BuildID[sha1]=73d88937de4f28a243ba40001af8dbd5c1ca3ac8, not stripped
>
> the ${CC} in makefile is defined as
> CC=gcc
> ____
> From: Burton, Ross
> Sent:
901 - 1000 of 1567 matches
Mail list logo
