Just tried the externalsrc feature. Works perfectly. Exactly what I was
looking for. Thanks so much, Rudolf!
--Russ
On Thu, Jul 25, 2019 at 4:59 PM Rudolf J Streif
wrote:
> Inlining below.
> On 7/25/19 8:14 AM, Russell Peterson wrote:
>
> I think I have a somewhat better unde
. PREMIRROR is
> the wrong approach for that.
>
> :rjs
> On 7/24/19 12:53 PM, Russell Peterson wrote:
>
> Hi, Rudolf.
>
> I apologize for not being clear. The idea here is that my recipe points
> to github while, for my local development environment, I set a premirror to
>
; SRC_URI = "git:///local/path/${PN};protocol=file"
>
> SRCREV = "${AUTOREV}"
>
> S = "${WORKDIR}/git"
>
> PREMIRRORS is only relevant for do_fetch not for do_unpack.
>
> :rjs
>
>
> On 7/24/19 11:28 AM, Russell Peterson wrote:
>
> Hi,
Thanks, Yi. I did try that and I see the tar file is created... but again,
the do_unpack function seems to ignore it and go directly to the github
repository.
--Russ
On Wed, Jul 24, 2019 at 4:28 AM Yi Zhao wrote:
>
> On 7/24/19 4:49 AM, Russell Peterson wrote:
>
> Hello,
>
&g
; devtool add myrecipe localsrc fetchuri
>
> from your build environment (you have to source oe-init-build-env first).
> devtool then fetches the source from fetchuri into a directory localsrc as
> a git repo and automatically creates the recipe for it.
>
> :rjs
>
>
> On 7
Hello,
I am looking to have bitbake pick up files for a particular recipe from a
local git repository using the PREMIRROR functionality.
Basically, the recipe (bb file) points to github but in my local build I
add PREMIRROR_prepend = "git://.*/.*
git:///local/path/BASENAME;protocol=file\n"
I wil
Hello,
I have what I would think is an unusual requirement regarding a kernel
module and could use some advice.
I have a kernel module that has been heavily modified... to the point where
we have a separate recipe for it and treat it as an out-of-tree module.
This works by not setting the kernel
Hello,
We are seeing build failures every now and then regarding our out of tree
modules.
I have tracked the issue down to make-mod-scripts performing the make
oldconfig and prepare operations. Normally this works, however, if for
some reason a clean is done on the linux kernel, the build artifa
Hello,
I’m trying to understand what the “normal” package arch should be when using
yocto to build for a specific SoC.
In my local.conf file I set my MACHINE value to “xSoc”. Because of that I see
RPM files being generated with arch “xSoC” (as well as “aarch64”).
I forgot to mention in my machi
e unless TMPDIR is set to the default (TOPDIR/tmp) the
SDK won't work??
Regards,
Russell
> On July 25, 2018 at 9:01 AM RUSSELL PETERSON wrote:
>
>
> So, this seems broken to me. I managed to get around this issue
> (sstate-control/manifest-allarch-kernel-devsrc.populate_sys
x86_64-nativesdk. Do I update ALL_MULTILIB_PACKAGE_ARCHS again?? Ug.
--Russ
> On July 24, 2018 at 8:36 AM RUSSELL PETERSON wrote:
>
>
> I am running Poky Rocko at the HEAD (just updated yesterday) and see the
> following when I attempt to build the eSDK:
>
> sstate-cont
the trail went silent so I'm not sure if there was a fix
or if that fix went into Rocko. Anyone?
--Russ
> On July 21, 2018 at 4:42 PM Russell Peterson wrote:
>
>
> No, just the standard SDK. I was having issues building the eSDK back when
> we used pyro and never fully fi
Jul 21, 2018, at 1:34 PM, Khem Raj wrote:
>
> On Sat, Jul 21, 2018 at 6:20 AM Russell Peterson
> wrote:
>>
>> Hello,
>>
>> I have been building some modules using the SDK for a while now. This is
>> mostly for development flow purposes but we have had a
Hello,
I have been building some modules using the SDK for a while now. This is
mostly for development flow purposes but we have had a few customers doing this
as well. To get this to work we always need to run “make silentoldconfig
scripts” inside the RFS of the SDK on the build host. Many
Hello,
I’m looking to change to openssl version 1.1. I’m using the rocko branch. I
have set PREFERRED_VERSION_openssl to 1.1%… but it doesn’t seem to work.
Anyone?
NOTE: Resolving any missing task queue dependencies
NOTE: preferred version 1.1.% of openssl not available (for item openssl10)
N
; 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
I am trying to install libxml2 for python2 in my image recipe. Seems like it
is being installed in the python3 site packages directory instead of the
python2 site packages directory. While looking into this I have become very
confused. Is there some documentation on this? Do I need to set so
is make sense to anyone?
> On April 3, 2018 at 7:42 PM Russell Peterson wrote:
>
>
> Hello,
>
> I have some out of tree modules that I have added to my custom meta layer.
> Normally things work fine, however, when I modify these recipes every now and
> then the do_confi
Hello,
I have some out of tree modules that I have added to my custom meta layer.
Normally things work fine, however, when I modify these recipes every now and
then the do_configure fails because the recipe_sysroot directory is not
populated. This seems related to the kernel-build-artifacts and
wrote:
>
> On 02/08/2018 03:17 AM, Russell Peterson wrote:
>> core-image-initramfs-1.0-r0 do_rootfs: Could not invoke dnf
>> Last metadata expiration check: 0:00:00 ago on Thu 08 Feb 2018 12:07:06 AM
>> UTC.
>> Error:
>> Problem: conflicting requests
>>
Hello,
I am upgrading from pyro to rocko and see something I can’t figure out (see
error below).
I can’t tell if this is dnf telling me there are multiple sources for python or
something else. Not sure what “conflicting” means. I do know that the rpm
produced by the of ofa-kernel recipe has
ote:
>
>
> Hey Russell
>
> I don't claim to be an authority on best practices but I will share some
> thoughts.
>
> On Sun, 2017-08-13 at 06:58 -0400, Russell Peterson wrote:
>> Hello.
>>
>> As I learn more about yocto and more importantly gain pract
Hello.
As I learn more about yocto and more importantly gain practical experience with
it I have started to think about my release structure. Is there a “best
practices” document or something like that that speaks to this?
For example, how does everyone deal with “external” meta layer dependen
/tasks.
Thanks again.
Russell
> On Aug 7, 2017, at 2:49 AM, Paul Eggleton
> wrote:
>
> Hi Russell,
>
> On Wednesday, 2 August 2017 8:34:11 PM CEST RUSSELL PETERSON wrote:
>> Frustrating in that I can't get the eSDK to fully build. I'm past the issue
>>
Thanks for the help but, no. I’m just trying to build the eSDK via the normal
bitbake process.
Russell
> On Aug 4, 2017, at 11:52 AM, Andrea Galbusera wrote:
>
> Hi,
>
> On Wed, Aug 2, 2017 at 8:34 PM, RUSSELL PETERSON <mailto:bluehil...@comcast.net>> wrote:
>
ctedly
On August 1, 2017 at 8:55 PM Russell Peterson wrote:
FYI: For those interested…
Just as a test/workaround I added a harfbuzz_%.bbappend file to my meta layer
and directly set the acpaths variable to the STAGING native directory and that
seems to work fine. Works for now but I will try
${STAGING_DATADIR_NATIVE}/aclocal/“
Regards,
Russell
> On Aug 1, 2017, at 5:52 PM, RUSSELL PETERSON wrote:
>
> Thank you for the response, Paul. You were correct that I had the
> TOOLCHAIN_*_TASK variables set in my machine.conf file. I put it into my
> image bb file and
the global level, which you really don't want to do if you're
> going to be building buildtools-tarball (which eSDK will build as a
> dependency). I'd suggest moving that setting to your image recipe.
>
> Cheers,
> Paul
>
> On Sunday, 30 July 2017 4:22:24 PM CE
Hello, all.
I’m trying to build the eSDK for my platform and I just can’t figure out why
dnf can’t find kernel-devsrc. It’s there, I added it. The “normal SDK” uses
it and builds fine. Just no luck with the eSDK.
Any help out there? Poky is pyro. aarch64 SoC target platform with an x86
bui
Hello,
I am currently building an SDK and a disk image using morty. Learning quite a
bit about Yocto.
Eventually I will distribute both the SDK and the rootfs image to customers. I
see that there is a license manifest generated for the full rootfs which is
very useful. My question is, what
Sorry. I'm doing 5 things at once here.
I am fetching a source RPM inside a simple RECIPE.
> On June 20, 2017 at 1:33 PM RUSSELL PETERSON wrote:
>
>
> Hello,
>
>
> I am fetching a src RPM file inside a simple library. The RPM basically
> contains a
Hello,
I am fetching a src RPM file inside a simple library. The RPM basically
contains a tar file with the source and 2 patch files. How to I apply those
patch files? If I put them in the SRC_URI the fetch fails. Is there a way I
can add them to some list that do_patche uses or do somethi
the response.
Russell
> On Jun 2, 2017, at 6:34 PM, Ayoub Zaki wrote:
>
>
>
> On 03.06.2017 00:26, Russell Peterson wrote:
>> Hello,
>>
>> I’m writing a new recipe and doing something I think should be simple but
>> instead causes an except
Hello,
I’m writing a new recipe and doing something I think should be simple but
instead causes an exception when expanding SRCPV.
SRCREV = “”
SRC_URI = “git://abc.com/xyz.git ”
PV = “1.2+git${SRCPV}
The above works fine. Problem is, when I add a patch I get an exception when
expa
rpm2cpio | cpio operation on the binary rpm…
and now see cpio malformed errors. My guess is the rpm uses compression… but
shouldn’t the rpm2cpio handle that??
Thanks again for the advice.
Russell
> On May 22, 2017, at 8:59 AM, Alexander Kanavin
> wrote:
>
> On 05/22/2017 02:43
Hello,
I am fairly new to yocto and I think I’m having trouble installing an RPM on
the rootfs. What I am trying to do is install an arm64 binary RPM file straight
onto the root file system without a recipe… just use the native rpm tool to put
it there. There are several reasons why I’m experi
36 matches
Mail list logo
