You're using busybox's scp, which is limited compared to openssh. If
you want to use openssh's binaries install openssh-clients, otherwise
adapt your options to work with busybox's scp.
Ross
On Thu, 25 Jul 2019 at 02:10, JH wrote:
>
> Hi,
>
> I am running busybox in imx6 using ssh and scp in
On Mon, 22 Jul 2019 at 21:13, Madhu Krishnamurthy wrote:
> INSANE_SKIP_mlc = "ldflags"
> INSANE_SKIP_mlc-dev = "ldflags"
> INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
> INHIBIT_PACKAGE_STRIP = "1"
>
> But after adding that I still get this error.
> ERROR: mem-tst-0.1 do_package_qa: QA Issue: No GNU_HASH in
On Thu, 18 Jul 2019 at 07:04, Adrian Bunk wrote:
> > Now that both Debian 8 and OpenSuse 42.3 are end-of-life and no longer
> > formally supported, we think it's time to drop them from the supported
> > distribution list.
>
> Debian 8 is still LTS-supported for a year, unless there is urgency to
Hi,
Now that both Debian 8 and OpenSuse 42.3 are end-of-life and no longer
formally supported, we think it's time to drop them from the supported
distribution list. Initially this involves removing them from the
SANITY_TESTED_DISTROS list in Poky, at some point during this cycle we
may remove
On Tue, 16 Jul 2019 at 17:45, Siegel, Jeffrey (Nokia - US/Murray Hill)
wrote:
> I am trying to use a bbappend file to patch a file in $WORKDIR. To my
> understanding, the native Yocto patching process only works for patching
> files in $S.
No, the default directory for patch application is $S
On Tue, 16 Jul 2019 at 18:37, Andy Pont wrote:
> ERROR: Nothing PROVIDES 'libepoxy' (but
> /home/me/yocto/sources/meta-webkit/recipes-browser/wpewebkit/wpewebkit_2.24.2.bb
> DEPENDS on or otherwise requires it)
> libepoxy was skipped: missing required distro feature 'opengl' (not in
>
The proper way would be to write a recipe for each package you wish to add.
Ross
On Tue, 16 Jul 2019 at 16:04, Andy Pont wrote:
>
> Hello,
>
> Is there a way to add node.js packages into a build? I’m trying to
> avoid having to include npm and compiler into my target image.
>
> -Andy.
>
> --
>
On Tue, 16 Jul 2019 at 13:53, Andy Pont wrote:
> I am building for a Microchip (Atmel) SAMA5D2 using meta-atmel. We don’t
> need OpenGL or 3D support - hence one of the reasons for picking the SAMA5D2
> which doesn’t have a hardware GPU.
>
> The options appear to be to either add software
Merged.
Ross
On Tue, 2 Jul 2019 at 17:03, Joshua Watt wrote:
>
> Adds support for building gnupg as a -native recipe.
>
> Signed-off-by: Joshua Watt
> ---
> recipes-support/gnupg/gnupg_1.4.7.bb | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/recipes-support/gnupg/gnupg_1.4.7.bb
On Fri, 12 Jul 2019 at 15:38, Moritz Porst wrote:
> If I use the .wic image, APPEND is ignored. You need to write your own
> kickstart file for this and include --append option. This usually means
> copy what you need from existing files (check license compliance) and
> add what you need. See
file /lib/firmware/ti-connectivity/wl18xx-fw-4.bin from install of
linux-firmware-wl12xx-1:0.0+git0+d114732723-r0.noarch conflicts with
file from package firmware-wireless-wilink8-1.0-r0.cortexa9hf_neon
file /lib/firmware/brcm/brcmfmac4330-sdio.bin from install of
On Wed, 3 Jul 2019 at 20:54, Chad Gong wrote:
> I opened the log.do_fetch file, and it looks like a file
> git2_github.com.thkukuk.libnsl.tar.gz was downloaded from the mirror site
> http://downloads.yoctoproject.org/mirror/sources/git2_github.com.thkukuk.libnsl.tar.gz
> .Then an error
On Thu, 4 Jul 2019 at 10:43, Zoran Stojsavljevic
wrote:
> Why Weston protocol? Why not classical X11 Client Server in user
> space? Which DeskTop are U using in Ur YOCTO build?
Weston is arguably superior to X11 in most respects, and for new
platforms which are not tied to a classic X server I
On Thu, 4 Jul 2019 at 09:46, Onur Eser wrote:
> Hello Yocto Community!
> When I was trying to build core-image-weston with meta-qt5 and meta-fsl-arm
> layer for my imx6 (Humming Board 2 - Armv7) board, it gave an error on
> compilation of the "jason-glib". I would suprised if my image was
On Wed, 3 Jul 2019 at 14:21, Chad Gong wrote:
> I re-ran another build of the same configuration. This time there is no fetch
> error for the file that failed last time. I looks each time I build, I get
> different fetch error randomly. But this time the failed URL is git shown
> below, and I
On Tue, 2 Jul 2019 at 19:22, Chad Gong wrote:
> Thank you for the advice. Which folder contains the recipe? Which method is
> used to calculate the checksum?
Please remember to ensure the list is copied.
$ find . -name opkg-util*bb
./meta/recipes-devtools/opkg-utils/opkg-utils_0.4.1.bb
You're
--.-KB/sin 0.005s
>
> 2019-07-01 20:11:02 (5.97 MB/s) - ‘opkg-utils-0.4.0.tar.gz’ saved [30536]
>
>
>
>
>
> Chad Gong
> Electrical Engineer
>
> Trijicon, Inc.
>
>
> | P.O. Box 930059
> Wixom, Michigan 48393 US
> cg...@trijicon.com |
>
> -
On Tue, 2 Jul 2019 at 13:53, Chad Gong wrote:
> WARNING: m4-native-1.4.18-r0 do_fetch: Failed to fetch URL
> http://ftp.gnu.org/gnu/m4/m4-1.4.18.tar.gz, attempting MIRRORS if available
$ wget http://ftp.gnu.org/gnu/m4/m4-1.4.18.tar.gz
URL transformed to HTTPS due to an HSTS policy
--2019-07-02
On Tue, 2 Jul 2019 at 08:05, Zoran Stojsavljevic
wrote:
> >> Runtime auto test for following platforms:
> >> 1. MinnowTurbot 32-bit (Appolo Lake?)
> >> 2. Coffee Lake (14nm 4th tock in the row)
> >> 3. NUC 7
> >> 4. NUC 6
> >> 5. Edgerouter
> >> 6. MPC8315e-rdb
> >> 7. BeagleboneHm...
>
> At
First, Fido/1.8 is very old: released in April 2015 and is now out of
support, has no security fixes, etc. So I'd first suggest upgrading
to a supported release.
If you can't, then the easiest thing to do would be to look at the
log.do_compile for that recipe in your build directory, or use ps
The bash parser does have some bugs, and I think you just found one.
Probably easier to have a template on disk in SRC_URI, and sed in the
value you want.
Ross
On Fri, 28 Jun 2019 at 19:35, Aaron Biver wrote:
>
> I'd like to be able to create a file using the cat command in a recipe. The
>
On Thu, 27 Jun 2019 at 17:58, John McCabe wrote:
> Exception: OSError: [Errno 40] too much recursions while resolving
> '/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds/usr/lib/libTAO_PI_Server.so.2.2a_p15';
> loop in
>
gt; Hi.
> Thank you. Could you tell me how I can ensure that these are on the same
> branch? There is just one meta-bbb I can download...
>
> Am Do., 27. Juni 2019 um 09:37 Uhr schrieb Burton, Ross
> :
>>
>> The problem is that oe-core and meta-bbb are different releas
The problem is that oe-core and meta-bbb are different releases so the
versions don't match up. Ensure that oe-core and meta-bbb are on the
same branch.
Ross
On Thu, 27 Jun 2019 at 07:33, danwe wrote:
>
> while using the command:
> daniel@daniel-VirtualBox:~/bbb$ MACHINE=beaglebone bitbake
On Tue, 25 Jun 2019 at 17:47, Elliott, Alexander L CIV USN
NAVSURFWARCEN DAH VA (USA) wrote:
> RDEPENDS_${PN} = "libgcc_s.so.1"
You RDEPENDS on other package, not filenames.
RDEPENDS_${PN} = "libgcc"
Ross
--
___
yocto mailing list
Yes, you're right, this is a bug in the new functionality.
The usual variables are in the data store, so you can get them with
e.g. d.getVar("http_proxy"), as you can clearly replicate the failure
would you be able to attempt a patch?
Ross
On Tue, 25 Jun 2019 at 11:14, Vignesh Rajendran
The image manifest lists what is being *distributed* so doesn't
include native dependencies.
Ross
On Mon, 24 Jun 2019 at 19:50, wrote:
>
> Hi,
> I’m currently working to remove all GPLv3 packages included in my image.
> I was using the license manifest file to list the remaining GPLv3 packages
Whoops. Done :)
On Fri, 21 Jun 2019 at 14:18, Martin Jansa wrote:
>
> No problem, thanks for quick response.
>
> Looks like this patch wasn't merged in master as well (I thought it was), can
> you please push it as well.
>
> Thanks
>
> On Fri, Jun 21, 2019 at
Done, sorry.
Ross
On Fri, 21 Jun 2019 at 13:53, Martin Jansa wrote:
>
> ping for warrior
>
> On Tue, Jun 11, 2019 at 9:08 AM Martin Jansa wrote:
>>
>> * bc can be provided by busybox as well (e.g. if you have your own
>> defconfig and forget to explicitly disable it:
>> ...
>> *
>> *
It's always a good idea to share sstate between builds.
Ross
On Mon, 17 Jun 2019 at 12:32, Gabriele Zampieri wrote:
>
> Hi all,
>
> is it a good idea to share the SSTATE_DIR between a docker container (used
> with GitLab pipelines) and the local bitbake instance? They both work on the
> same
On Sun, 9 Jun 2019 at 23:19, Ulf Samuelsson wrote:
> When you have the same machine, and the recipes have variants
> which are DISTRO dependent the SSTATE_DIR can be messed up
>
> We never digged deep enough to find the cause,
> but when we separated the SSTATE to only have one DISTRO
> in the
That is deliberate and by design, recipes shouldn't fetch from
Debian/Ubuntu archives for this reason.
http://git.yoctoproject.org/cgit/cgit.cgi/meta-security/commit/?id=462d76700a3c2748067d4685db8985c511b1b46c
is a patch to master that needs to be backported to warrior/thud/sumo.
Ross
On Fri,
Sounds like the makefiles are broken and can't handle out-of-tree
builds. Try replacing inherit autotools with inherit
autotools-brokensep (and if that fixes it, file a bug with jool as
their build is broken).
Ross
On Thu, 6 Jun 2019 at 17:27, Gokul Raj wrote:
>
> Hi All,
>
> I'm new to yocto
Pushed, thanks.
Ross
On Wed, 5 Jun 2019 at 08:56, Martin Jansa wrote:
>
> Signed-off-by: Martin Jansa
> ---
> recipes-devtools/elfutils/elfutils_0.148.bb | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/recipes-devtools/elfutils/elfutils_0.148.bb
>
On Mon, 3 Jun 2019 at 15:06, Morné Lamprecht wrote:
> I also have DISTRO_FEATURES_BACKFULL_CONSIDERED =
> "sysvinit" in my config (also had it during the
> failed builds), I thought it would prevent
> sysvinit from being added/backfilled to the
> DISTRO features ? So I'm not sure why
>
On Thu, 30 May 2019 at 21:27, Serkan Türker wrote:
> I understand the process of debugging build failures. I am just confused why
> my approach doesn't work.
> "python-soundcloud.bb" has the same format like other python module recipes
> in meta-oe.
> In tizonia.bb, I have added
gt; https://www.debian.org/doc/debian-policy/ch-controlfields.html#list-of-fields
> >
> >
> > We had to pick a convention. Debian is well documented, conservative and
> > well thought out. My first contributions to OpenEmbedded many years ago
> > didn’t follow Debian naming,
On Sat, 25 May 2019 at 14:28, Archana Polampalli
wrote:
> i am working on one open source project,for this i have to add some
> debian packages as yocto recipies.
> i am trying to add "audit" recipe,so iam trying to understand the audit
> debian package ,i got struck between "depends" and
On Fri, 24 May 2019 at 07:30, Norman Stetter
wrote:
> For the OS image I use cpio.gz as file system. It gets booted as a
> RAMdisk. Sorry, forgot to mention that.
>
Would you consider switching to a proper filesystem? The peril of using a
cpio.gz is that every file you add slows the boot down:
The meta-intel BSP is the recommend BSP for all Intel platfoms.
Ross
On Fri, 24 May 2019 at 10:30, Ranran wrote:
>
> Hello,
>
> I searched for ATOM N450 recipe, but only found very old one:
> https://old.yoctoproject.org/downloads/bsps/edison11/atom-pc
> The problem is that we need newer gcc
On Thu, 23 May 2019 at 10:43, virendra kumar thakur
wrote:
> But I can see in
> rootfs/usr/share/common-license/package/libgcrypt-lic/recipeinfo
>
> LICENSE: GPLV2+ + +
> PR: r0
> PV : 1.8.4
At a guess, because the libgcrypt recipe is:
LICENSE = "GPLv2+ & LGPLv2.1+ & GPLv3+"
Whereas libgcrypt
On Thu, 23 May 2019 at 13:46, Norman Stetter
wrote:
> That seems to be a misunderstanding. I want to keep the OS image as small
> as possible to reduce boot time. We only use python for some test
> scenarios, so it doesn’t have to be included in the OS image. I did some
> measurements and
On Wed, 22 May 2019 at 14:28, Norman Stetter
wrote:
> Is there a way to have dependencies between images? So I could have the
> python-image build know which dependencies are already built into my OS
> image and therefore not include them itself?
>
No. An image is a self-contained file system.
On Wed, 22 May 2019 at 06:26, virendra kumar thakur
wrote:
> still some package gnutls, libidn2, libassuan, are added into rootfs.
Randomly picking libassuan:
LICENSE_${PN} = "LGPLv2.1+"
The library itself is LGPL-2. Have you verified the *package*
licenses for what is actually going into the
On Mon, 13 May 2019 at 09:54, Matthias Schoepfer
wrote:
> I am trying to write a recipe for a rather tricky component (that has
> plugins and stuff). Anyhow, I cannot get bitbake not to complain that
> rdepends on -dev. And if I INSANE_SKIP it,
> the -dev package will get installed. But I cannot
On Sat, 11 May 2019 at 21:32, Madhu Krishnamurthy wrote:
> If I have to chose just one, will any one of them (say apt) work? I somehow
> had come to believe that you can only use opkg in Yocto.
The default is opkg but RPM and dpkg are supported. I'd pick either
opkg or rpm though.
Ross
--
On Sat, 11 May 2019 at 00:54, Madhu Krishnamurthy wrote:
> Do I have to specify every package or is there a way I can add all packages
> inside a layer?
> For example, how do I add all packages from inside poky/meta to my image?
> Or at least how do I add all packages under
On Thu, 9 May 2019 at 10:47, Fabian Knapp wrote:
> we have multiple MACHINEs and DISTROs and Im wondering for which
> combinations I have to setup a dedicated build dir, SSTATE_DIR and DL_DIR.
>
> Information in the form of:
>
> Each (change of) MACHINE needs its dedicated SSTATE_DIR and build
On Mon, 6 May 2019 at 17:28, Eric Grunt wrote:
> | configure: error: C compiler cannot create executables
> | See `config.log' for more details
I suggest reading config.log for more details.
Ross
--
___
yocto mailing list
yocto@yoctoproject.org
On Fri, 3 May 2019 at 07:46, Jaquier Cyril wrote:
> There are a few other solutions available for Yocto:
>
> https://wiki.yoctoproject.org/wiki/System_Update#Comparison
That list needs updating as there's a few more available now such as
Balena and UpdateHub, but both Mendor and swupdate are
Why don't you use the layer that comes with the Intel compiler?
Ross
On Thu, 2 May 2019 at 23:15, wrote:
>
> Hi,
>
> I'm currently working on repackaging the 2016 Intel compiler and I am
> stuck at the dependency resolution.
>
> I am basing my recipe on the AUR PKGBUILD [1], which extracts the
On Wed, 1 May 2019 at 23:33, JH wrote:
> It was my program, it has been compiled for weeks without any issues
> until I added an #include , despite the glib-2.0 was defined
> in the recipe, the do_compile() stopped at following errors, I can see
> glib-2.0 was built in build and image directory,
On Mon, 29 Apr 2019 at 10:48, Zolee K wrote:
> I guess something is wrong with the do-install function, I thought it would
> put the file in the image, but it doesn't. Please help me out on this.
Bitbake is literally telling you want to do:
> Please set FILES such that these items are
On Wed, 24 Apr 2019 at 13:29, Erik Hoogeveen wrote:
> What I have is:
>
> SRCREV = "${AUTOREV}"
> PE = "1"
> PV = "0.0+git${SRCPV}"
>
> To make that work your recipe file name must have the format
> '_git.bb’
Some corrections.
If you're using a git URL then you need to set SRCREV to the sha
On Wed, 24 Apr 2019 at 12:50, Archana Polampalli
wrote:
>
> Thank you for your responce
>
> whaile configuration time getting this error
> checking for EXT2FS... no
> INFO - | checking for EXT2FS... no
> INFO - | configure: error: Package requirements (ext2fs) were not
>
It means that the compile didn't respect LDFLAGS from the environment
(which sets the ELF hashing type). Most usual build systems handle
this for you, but if your recipe uses hand-coded Makefiles then you'll
need to figure out what they're doing and how to make it respect
$LDFLAGS.
Ross
On Tue,
Works for me. What is the actual error you're seeing?
On Tue, 23 Apr 2019 at 10:17, Archana Polampalli
wrote:
>
> Hi all,
>
> I am trying to build btrfs-tools recipes.it needs the ex2fs.pc
> pkgconfig file.i have alredy installed e2fsprogs recipe it created the
> ex2fs.pc in image directory.but
The problem is that config.guess, last modified 2009-09-18, has failed
to recognize the operating system you are using. It is advised that
you download the most up to date version of the config scripts from
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD
:11:04 +0100
> "Burton, Ross" wrote:
>
> > So for me they're in python3-twisted-core on target, and if you have
> > the right DEPENDS then it should be there for build time.
>
> I will have a look at this, when I'm back in the office again.
> The thing is, I nee
On Tue, 9 Apr 2019 at 11:14, Robert P. J. Day wrote:
> so, to confirm what i thought, this is a bug in gnulib which
> suggests i should dig through the build configuration to see where i
> can, say, set a PREFERRED_VERSION of a newer version of gnulib that
> no longer has tat bug? or, barring
So for me they're in python3-twisted-core on target, and if you have
the right DEPENDS then it should be there for build time.
Ross
On Tue, 9 Apr 2019 at 11:03, Guenther Meyer wrote:
>
> On Tue, 9 Apr 2019 10:55:38 +0100
> "Burton, Ross" wrote:
>
> > Specifica
On Tue, 9 Apr 2019 at 08:49, Guenther Meyer wrote:
>
> On Fri, 5 Apr 2019 18:17:43 +0100
> "Burton, Ross" wrote:
>
> > What metadata in particular do you refer to?
>
> The *egg-info folders and everything contained in them, especially
> the files PKG-INFO o
Looks like that bug in gnulib that broke m4 (and others) when glibc changed.
Fixed upstream
https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=4af4a4a718
and oe-core master/thud/possibly sumo also carry the relevant patch
for m4.
If you're using older releases against a newer release then
There must be if example.com can't be downloaded from...
On Mon, 8 Apr 2019 at 19:49, Karshi Hasanov wrote:
>
> There is nothing wrong with my network network!
>
> For now the issue is resolved.
>
> Thanks any way.
>
>
> On 2019-04-08 1:10 p.m., Burton, Ross wrote:
&
The better fix is to fix your network. If you need a proxy, set it in
local.conf.
Ross
On Mon, 8 Apr 2019 at 18:09, Nataliya Korovkina
wrote:
>
> Hello Karshi,
>
> I had the same message. I added:
>
> CONNECTIVITY_CHECK_URIS=""
>
> in conf/local.conf as a QUICK FIX. I hope someone has better
On Mon, 8 Apr 2019 at 07:17, Pandey, Kamal wrote:
> Hi I was trying to compile Weston-6.0 using yocto recipe. For this I
> backported some of the packages from master branch of poky to my own layer.
> During this process, there was one package xorgproto which was used in master
> branch of
What metadata in particular do you refer to?
Ross
On Thu, 4 Apr 2019 at 11:04, Guenther Meyer wrote:
>
> Hi,
>
> I added some python recipes for my application, and now I have the
> problem, that in some of the created packages the metadata is missing.
> For example, the package I have for
Hi,
I'm looking for some users that use the ISO images generated by
Bitbake (IMAGE_FSTYPE live or iso). Anyone out there?
Ross
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
On Tue, 2 Apr 2019 at 20:46, Tom Rini wrote:
> > The kernel does not have "upgrade foo to the latest upstream version"
> > commits.
> >
> > With the Automatic Upgrade Helper this is a semi-automatic task, and
> > most of the time there is no specific motivation other than upgrading
> > to the
On Tue, 2 Apr 2019 at 12:36, Ralf Spiwoks wrote:
> TWO questions:
>
> 1) Are those two issues related?
Probably not, unless you're trying to use a mixed-case override.
> 2) What is the logic behind allowing only lower case package names? This is
> to me
> a serious restriction on the use
On Fri, 29 Mar 2019 at 12:49, Clemens Eisserer wrote:
> The issue was the _$PN appended to DEPENDS, when I removed it the build
> succeeded:
> changing DEPENDS_${PN} = "luajit" to DEPENDS = "luajit" did the trick.
Right, DEPENDS_${PN} isn't a variable that is used. You'll most
likely have got
All I can say is stop digging around random paths and actually ask the
system the questions you need answers to.
- Does my recipe depend on luajit.
Check that you have DEPENDS=luajit.
- What files does luajit ship.
$ oe-pkgdata-util list-pkg-files -p luajit
Does that include a
On Fri, 29 Mar 2019 at 00:06, Clemens Eisserer wrote:
> Hi Burton,
>
> > > RDEPENDS_${PN} = "luajit"
> > > inherit autotools pkgconfig
> >
> > Considering you're trying to use luajit at build time, it's probably
> > sensible to have it as a build dependency instead (DEPENDS).
>
> I've just tried
On Thu, 28 Mar 2019 at 23:45, Clemens Eisserer wrote:
> The bb-file specifies luajit as runtime-dependency as well as inherits
> pkgconfig:
>
> RDEPENDS_${PN} = "luajit"
> inherit autotools pkgconfig
Considering you're trying to use luajit at build time, it's probably
sensible to have it as a
On Thu, 28 Mar 2019 at 12:40, Gabriele Zampieri wrote:
> So I just specify the dependencies in my recipes, and then remove
> IMAGE_INSTALL_append = " boost". Am I right?
Yes. Your recipe that uses boost just needs DEPENDS=boost as a
build-dependency. The linkage will be examined and the
On Thu, 28 Mar 2019 at 10:59, Gabriele Zampieri wrote:
> I'm building a custom image that install boost libraries:
>
> IMAGE_INSTALL_append = " boost"
>
> How can I trim the installed libraries? I see inside
> meta/recipes-support/boost/boost.inc a variable called BOOST_LIBS that lists
> all
On Fri, 15 Mar 2019 at 17:00, Derek Dresser wrote:
> | gcc -fPIC -c -g -MMD -MP -MF build/Debug/GNU-Linux-x86/hid.o.d -o
> build/Debug/GNU-Linux-x86/hid.o hid.c
'gcc' isn't a cross compiler, and it isn't using the sysroot flags.
The problem with people writing their own makefiles is that
On Wed, 6 Mar 2019 at 22:27, Kaz Kylheku (poky)
<442-103-8...@kylheku.com> wrote:
> Ah, okay; this is because it's been split into various sub-packages. So
> we have to operate on "-core".
> The .json manifest brings these into the "core" package:
>
> "${libdir}/python2.7/encodings",
On Wed, 6 Mar 2019 at 20:14, Kaz Kylheku (poky)
<442-103-8...@kylheku.com> wrote:
> So, the issues are now is that
>
> FILES_${PN}_remove = "${libdir}/python2.7/encodings"
>
> in fact does not work, as I believed.
Have a look at python.bb. Specifically:
PACKAGES_remove = "${PN}"
There is no PN
On Thu, 28 Feb 2019 at 05:20, Adrian Bunk wrote:
> > That's a good start. For a oe-core packagegroup
>
> I do not think a core-only packagegroup makes sense when the goal is to
> completely replace busybox (and not just most apps while keeping a few
> busybox apps installed).
But a "close
On Thu, 28 Feb 2019 at 00:10, Jean-Christian de Rivaz
wrote:
> My image recipe look actually like below and require several
> meta-openembedded/meta-*. This is not a clean example. The
> packagegroup-core-full-cmdline already provides a chunk of commands but
> more are required to look like a
On Wed, 27 Feb 2019 at 23:55, Tom Rini wrote:
> My current incomplete list is:
> bind-utils \
> bridge-utils \
> coreutils \
> dnsmasq \
> e2fsprogs \
> e2fsprogs-resize2fs \
> e2fsprogs-tune2fs \
> findutils \
> gawk \
> grep \
> inetutils-ping \
>
On Wed, 27 Feb 2019 at 22:25, Jean-Christian de Rivaz
wrote:
> The project I work for need nodejs and chromium (and a >100MB database
> on some nodes), so space is not an issue. I need to deliver an useful
> distribution with usual commands, tools and a working console + keyboard
> for my locale.
On Wed, 27 Feb 2019 at 21:41, Adrian Bunk wrote:
> It is not obvious to me what usecases people have in mind for
> getting rid of busybox, and whether everyone is aware that
> something like "all busybox commands replaced" is *very*
> expensive regarding filesystem size.
Considering many of the
On Wed, 27 Feb 2019 at 18:45, Tom Rini wrote:
> OK, so I've kicked things a bit harder again, and here's what I see as
> the (small) rub.
> $ git grep hddimg meta/conf/
> meta/conf/machine/include/x86-base.inc:IMAGE_FSTYPES ?= "hddimg"
>
> So yes, we can do a test with qemux86/qemux86-64 and
On Wed, 27 Feb 2019 at 17:58, Tom Rini wrote:
> I'm not sure we can blacklist busybox from the build at this time
> (hddimg requires initramfs that requires busybox) but instead only force
> remove it from the image and ensure it still builds.
Don't build an image with a initramfs?
--
On Wed, 27 Feb 2019 at 17:27, Mark Hatle wrote:
> You can also blacklist busybox to ensure that it never builds, and thus can't
> show up in your target image.
>
> PNBLACKLIST[busybox] = "Don't build this"
Sounds like someone should write a new selftest that does the required
configuration
On Mon, 25 Feb 2019 at 12:14, chaitanya cherukuri
wrote:
>> If I understand correctly, you want to me copy what script is doing in
>> do_install(). I was thinking to add the script has startup to a YOCTO
>> Image, so that I don't need to copy anything manually and let the script to
>> its
On Mon, 25 Feb 2019 at 00:45, chaitanya cherukuri
wrote:
> Thank you for the clarification.
> In do_install(), I used rpm2cpio.sh to extract the rpm and then copied the
> rpm contents in the right place.
> $rpm2cpio.sh *.rpm | cpio -idmv
> I hope this is the right way to handle RPM
On Fri, 22 Feb 2019 at 22:16, chaitanya cherukuri
wrote:
> Do I need to write a recipe where I fetch this package?
Yes, write a recipe that has SRC_URI as the original RPM, then you can
write a do_install() to put the files in the right place, package it
correctly, and so on.
Just using the RPM
+1, feel free to push.
Ross
On Wed, 20 Feb 2019 at 21:35, Joshua Watt wrote:
>
> The command to properly set the exit code at the end of the toolchain
> environment was using the correct flag delimiter '/', but the code to
> coerce all the unix-style paths to windows paths was incorrectly
>
Looks good to me, feel free to push.
Ross
On Wed, 20 Feb 2019 at 21:14, Joshua Watt wrote:
>
> Upgrade diffutils from 3.6 to 3.7. The upstream made several fixes so
> the local patches are no longer necessary, but the gnulib-tests need to
> be dropped since they do not compile properly. Since
On Thu, 14 Feb 2019 at 20:29, Chuck Wolber wrote:
> I have run across this a few times, particularly with man pages, when
> including upstream packages into my images.
>
> I have to use a bbappend recipe in my meta layer to remove the lower priority
> version.
If you've two manpages with the
Two packages can't install the same file. In this case I suspect
you'll need to split up the packaging further. A common alternative
for binaries in /bin which want to be installed by both e.g. coreutils
and busybox is to use update-alternatives.
Ross
On Thu, 14 Feb 2019 at 16:36, madoga
It's part of mesa-demos.
Ross
On Tue, 12 Feb 2019 at 16:14, Peter Balazovic wrote:
>
> I'd like to ask which yocto recipe has "glxinfo" available? I will make
> available that package within local.conf...
>
> Thanks.
> Peter
> --
> ___
> yocto
You're probably not depending on the entire library so you only get
what you ask for. Instal python3-modules and you'll get all of the
standard library.
On Tue, 12 Feb 2019 at 16:14, Emily Smith wrote:
>
> Hi -
>
> I’ve been working with yocto and with some code running on my OS, however I’m
>
You're probably using DISTRO=poky, which now disables static libraries.
This is the periodic reminder for the list that the Poky distro is an
example, and does change over time. If you want control over the distro
then create your own distro.
Ross
On Sat, 9 Feb 2019 at 00:01, Greg
eferenced by the manifest file, the archiver does extract
> no source packages:
> - libgcc
> - gcc-runtime
> Why is that ?
>
> Regards,
> David
>
> > Am 31.01.2019 um 15:46 schrieb Burton, Ross :
> >
> > Please remember to keep the list on CC.
>
were installed in a good order until this showed
> up. I had backported some of these changes to 'daisy' before realizing
> that the groups simply hadn't been created yet.
>
>
>
> On Thu, 2019-01-31 at 10:52 +, Burton, Ross wrote:
> > Forgot to say, B
o my image.
> As a countercheck I see what licenses will be placed in the image
> (COPY_LIC_DIRS = 1 && COPY_LIC_MANIFEST = 1) which reflects the limited
> number of packages I do expect.
>
> Regards,
> David
>
> > Am 31.01.2019 um 11:11 schrieb Burton, Ross :
&g
1 - 100 of 1487 matches
Mail list logo
