date:20170831

Re: [yocto] [meta-security][PATCH] fail2bin: Add new package

2017-08-31 Thread Paul Eggleton

Hi Armin,

On Friday, 1 September 2017 5:09:23 PM NZST Armin Kuster wrote:
> Fail2Ban scans log files like /var/log/auth.log and bans IP addresses having 
> too 
> many failed login attempts. It does this by updating system firewall rules to 
> reject 
> new connections from those IP addresses, for a configurable amount of time. 
> Fail2Ban comes out-of-the-box ready to read many standard log files, such as 
> those for sshd and Apache, and is easy to configure to read any log file you 
> choose, for any error you choose.
> ...
> +++ b/recipes-security/fail2ban/fail2ban_0.10.0.bb
> @@ -0,0 +1,41 @@
> +SUMMARY = "Daemon to ban hosts that cause multiple authentication errors."
> +DESCIPTION = "Fail2Ban scans log files like /var/log/auth.log and bans IP 
> addresses having too \

Typo ^. Also typo "fail2bin" in the shortlog.

Great to see this added though, and that it's alive upstream - I wrote a recipe
for fail2ban a few years ago (around the 0.8.4 times) and then noticed it had
a number of security issues and so I dropped it. I just found I still have the 
recipe
and I was doing a few things like sed'ing the hardcoded paths in the config
and setting CONFFILES that you don't have here, so I could send you a patch
afterwards with those tweaks if you like.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-security][PATCH] fail2bin: Add new package

2017-08-31 Thread Armin Kuster

Fail2Ban scans log files like /var/log/auth.log and bans IP addresses having 
too many failed login attempts. It does this by updating system firewall rules 
to reject new connections from those IP addresses, for a configurable amount of 
time. Fail2Ban comes out-of-the-box ready to read many standard log files, such 
as those for sshd and Apache, and is easy to configure to read any log file you 
choose, for any error you choose.

Though Fail2Ban is able to reduce the rate of incorrect authentications 
attempts, it cannot eliminate the risk that weak authentication presents. 
Configure services to use only two factor or public/private authentication 
mechanisms if you really want to protect services.

Signed-off-by: Armin Kuster 
---
 recipes-security/fail2ban/fail2ban_0.10.0.bb  |  41 +
 recipes-security/fail2ban/files/fail2ban_setup.py | 175 ++
 recipes-security/fail2ban/files/initd |  98 
 3 files changed, 314 insertions(+)
 create mode 100644 recipes-security/fail2ban/fail2ban_0.10.0.bb
 create mode 100755 recipes-security/fail2ban/files/fail2ban_setup.py
 create mode 100644 recipes-security/fail2ban/files/initd

diff --git a/recipes-security/fail2ban/fail2ban_0.10.0.bb 
b/recipes-security/fail2ban/fail2ban_0.10.0.bb
new file mode 100644
index 000..1beeb5b
--- /dev/null
+++ b/recipes-security/fail2ban/fail2ban_0.10.0.bb
@@ -0,0 +1,41 @@
+SUMMARY = "Daemon to ban hosts that cause multiple authentication errors."
+DESCIPTION = "Fail2Ban scans log files like /var/log/auth.log and bans IP 
addresses having too \
+many failed login attempts. It does this by updating system firewall rules to 
reject new \
+connections from those IP addresses, for a configurable amount of time. 
Fail2Ban comes \
+out-of-the-box ready to read many standard log files, such as those for sshd 
and Apache, \
+and is easy to configure to read any log file you choose, for any error you 
choose."
+HOMEPAGE = "http://www.fail2ban.org;
+
+LICENSE = "GPL-2.0"
+LIC_FILES_CHKSUM = "file://COPYING;md5=ecabc31e90311da843753ba772885d9f"
+
+SRCREV ="c60784540c5307d16cdc136ace5b395961492e73"
+SRC_URI = " \
+   git://github.com/fail2ban/fail2ban.git;branch=0.10 \
+   file://initd \
+   file://fail2ban_setup.py \
+"
+
+inherit update-rc.d setuptools
+
+S = "${WORKDIR}/git"
+
+INITSCRIPT_PACKAGES = "${PN}"
+INITSCRIPT_NAME = "fail2ban-server"
+INITSCRIPT_PARAMS = "defaults 25"
+
+do_compile_prepend () {
+cp ${WORKDIR}/fail2ban_setup.py ${S}/setup.py
+}
+
+do_install_append () {
+   install -d ${D}/${sysconfdir}/fail2ban
+   install -d ${D}/${sysconfdir}/init.d
+   install -m 0755 ${WORKDIR}/initd 
${D}${sysconfdir}/init.d/fail2ban-server
+}
+
+FILES_${PN} += "/run"
+
+INSANE_SKIP_${PN}_append = "already-stripped"
+
+RDEPENDS_${PN} = "sysklogd iptables sqlite3 python python-pyinotify"
diff --git a/recipes-security/fail2ban/files/fail2ban_setup.py 
b/recipes-security/fail2ban/files/fail2ban_setup.py
new file mode 100755
index 000..a5d4ed6
--- /dev/null
+++ b/recipes-security/fail2ban/files/fail2ban_setup.py
@@ -0,0 +1,175 @@
+#!/usr/bin/env python
+# emacs: -*- mode: python; py-indent-offset: 4; indent-tabs-mode: t -*-
+# vi: set ft=python sts=4 ts=4 sw=4 noet :
+
+# This file is part of Fail2Ban.
+#
+# Fail2Ban is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# Fail2Ban is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with Fail2Ban; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, 
USA.
+
+__author__ = "Cyril Jaquier, Steven Hiscocks, Yaroslav Halchenko"
+__copyright__ = "Copyright (c) 2004 Cyril Jaquier, 2008-2016 Fail2Ban 
Contributors"
+__license__ = "GPL"
+
+import platform
+
+try:
+   import setuptools
+   from setuptools import setup
+   from setuptools.command.install import install
+   from setuptools.command.install_scripts import install_scripts
+except ImportError:
+   setuptools = None
+   from distutils.core import setup
+
+# all versions
+from distutils.command.build_py import build_py
+from distutils.command.build_scripts import build_scripts
+if setuptools is None:
+   from distutils.command.install import install
+   from distutils.command.install_scripts import install_scripts
+try:
+   # python 3.x
+   from distutils.command.build_py import build_py_2to3
+   from distutils.command.build_scripts import build_scripts_2to3
+   _2to3 = True
+except ImportError:
+

Re: [yocto] [layerindex-web][PATCH v4] Asynchronous email notifications, task execution

2017-08-31 Thread Paul Eggleton

Hi Diana,

On Friday, 25 August 2017 5:20:30 PM NZST Diana Thayer wrote:
> This patch adds asynchronous task execution using a Celery backend
> and RabbitMQ task queue, so that the layer submission process to
> proceed even in the event that sending the notification email fails,
> and establishing an asynchronous execution mechanism that we can use
> in the future e.g. for triggering parse operations from the web UI.
> This pertains to bug 11195:
> 
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=11195
> 
> It updates the README to reflect the installation and configuration
> of a basic RabbitMQ setup, adds a 'tasks.py' file to contain task
> definitions, updates the 'edit_layer_view' function to send
> emails to administrators about new and updated layers asynchronously,
> and modifies the 'settings.py' to include a default configuration
> for a RabbitMQ connection.
> 
> Signed-off-by: Diana Thayer 

Thanks! I've just merged this, with your changes to the dockerfile in the 
other patch squashed in. I did tweak the commit message just a little, fixing 
the bug reference and adding mention of the dockerfile change.

I'll get in touch with Michael Halstead about updating the OE index instance.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Python recipes wanted?

2017-08-31 Thread Tim Orling

When you say "meta-oe", I assume you mean "meta-openembedded/meta-python"
[1]. That layer is where they belong.

There is no rule as to what is "wanted", but since you took the trouble to
write recipes, we can all benefit from your effort. But, I would add some
general guidelines:

1. Make sure the python package is the latest release and the patch applies
on top of "master".
2. Use the pypi.bbclass [2] with  "inherit pypi" to simplify the recipe (no
SRC_URI for pythonhosted is needed)
3. Many folks are still using Python 2 as well, so many recipes put the
heart of the metadata in an ".inc" file and the ${PYTHON_PN} (expands to
python or python3) version specific things (e.g. "inherit setuptools3") in
the .bb file. There are many examples in meta-python. This is not a
requirement, but is strongly encouraged.
4. Help maintain the recipes in meta-python. Don't just send your recipe
and never look at it again. The amount of metadata in meta-openembedded is
a challenge to maintain [3]. Maintenance is aided by, for instance, adding
INHERIT += "distrodata" [4] to your local.conf and running "bitbake
python-foo -c check_pkg" to check for new upstream versions [5]. You can
also run "distrodata" on your entire image [6]. This can be automated.

Also, looking at your python*-uvloop issue on Github [7], if upstream does
not want the patches that is OK, just include them with your recipe for
meta-python and put "Upstream-Status: Inappropriate (embedded specific)" or
similar in the patch itself. See the commit patch message guidelines [8].
You should also follow the README in meta-python [9] and the OpenEmbedded
patch submission guidelines [10].

[1] http://git.openembedded.org/meta-openembedded/tree/meta-python
[2]
http://git.openembedded.org/meta-openembedded/tree/meta-python/classes/pypi.bbclass
[3]
http://www.openembedded.org/wiki/Bitbake_World_Status_Rocko#Failed_tasks_2017-08-31
[4]
http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#ref-classes-distrodata
[5]
http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#structure-build-tmp-log
[6]
http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#ref-tasks-distrodata
[7] https://github.com/MagicStack/uvloop/issues/104
[8] http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
[9] http://git.openembedded.org/meta-openembedded/tree/meta-python/README
[10] http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded

On Thu, Aug 31, 2017 at 6:40 PM, Craig McQueen  wrote:

> I have made a number of recipes for Python packages, for my own use. Does
> meta-oe have an interest in any/all Python package recipe contributions, or
> ones that are considered more popular?
>
> I have:
>
> python3-aiohttp_2.2.3.bb
> python3-aiohttp-jinja2_0.13.0.bb
> python3-aiohttp-session_1.0.0.bb
> python3-async-timeout_1.2.1.bb
> python3-cobs_1.1.3.bb
> python3-colorlog_2.10.0.bb
> python3-configargparse_0.12.0.bb
> python3-lru-dict_1.1.6.bb
> python3-pycrypto_2.6.1.bb
> python3-pyserial-asyncio_0.4.bb
> python3-uvloop_0.8.0.bb
> python3-yarl_0.11.0.bb
>
> python-cobs_1.1.3.bb
> python-lru-dict_1.1.6.bb
>
> --
> Craig McQueen
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] apt-key not found

2017-08-31 Thread yahia farghaly

Hi,
I have built an image with deb package support and for authorization of the
incoming packages, i have to transfer a public key to the image and do the
command apt-key add . i do this for the first time the image is
booting but i want to automate the process when i build the image.
i have already created recipe which copy the public key to image rootfs
under /deb_key/keyFile then i tried to perform apt-key command in the image
recipe with

ROOTFS_POSTPROCESS_COMMAND += "addkeyfile;"
>
>
>> addkeyfile(){
>
> apt-key add ${D}/deb_key/keyFile
>
> }
>
>
but it gives me an error log of

>
>1. | NOTE: Executing empty_var_volatile ...
>2. | DEBUG: Executing shell function empty_var_volatile
>3. | DEBUG: Shell function empty_var_volatile finished
>4. | NOTE: Executing addkeyfile ...
>5. | DEBUG: Executing shell function addkeyfile
>6. |
>
> /home/yahia/Desktop/elinux_dev/bake_factory/poky-pyro-17.0.1/build/tmp/work/qemux86_64-poky-linux/apt-image/1.0-r0/temp/run.addkeyfile.12587:
>108:
>
> /home/yahia/Desktop/elinux_dev/bake_factory/poky-pyro-17.0.1/build/tmp/work/qemux86_64-poky-linux/apt-image/1.0-r0/temp/run.addkeyfile.12587:
>apt-key: not found
>7. | WARNING: exit code 127 from a shell command.
>8. | DEBUG: Python function do_rootfs finished
>9. | ERROR: Function failed: addkeyfile (log file is located at
>
> /home/yahia/Desktop/elinux_dev/bake_factory/poky-pyro-17.0.1/build/tmp/work/qemux86_64-poky-linux/apt-image/1.0-r0/temp/log.do_rootfs.12587)
>10. ERROR: Task
>
> (/home/yahia/Desktop/elinux_dev/bake_factory/poky-pyro-17.0.1/meta-mylayer/recipes-example/images/apt-image.bb:do_rootfs)
>failed with exit code '1'
>
>
So, what the right way to do this ?

Thanks,

-- 
Yahia Farghaly
Graduated from Faculty of Engineering - Electronics and Communications
Department at Cairo University.
Linkedin  - GitHub




‌
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Python module and build_ext args

2017-08-31 Thread Craig McQueen

I wrote:
> Khem Raj wrote:
> > On Thu, Aug 24, 2017 at 9:42 PM, Craig McQueen
> >  wrote:
> > > Khem Raj wrote:
> > > On Thu, Aug 24, 2017 at 6:48 PM Craig McQueen
> > > 
> > > wrote:
> > >
> > > I wrote:
> > >> I'm trying to make a recipe for python3-uvloop, using setuptools3.
> > >>
> > >> The Python 3 uvloop module depends on libuv. It bundles a version
> > >> of libuv, and setup.py tries to build it, but it doesn't work well
> > >> for cross-compilation.
> > >> However, it also provides a build_ext parameter
> > >> "--use-system-libuv", which seems to work when I try running it
> > >> manually in devshell. (I have made a suitable recipe for libuv and
> > >> added libuv to DEPENDS.)
> > >>
> > >> How can I specify the "--use-system-libuv" parameter for build_ext
> > >> in the python3-uvloop recipe? I see a reference to
> > >> DISTUTILS_BUILD_EXT_ARGS, but it doesn't seem to be functional.
> > >
> > >
> > > I see DISTUTILS_BUILD_EXT_ARGS was submitted in this patch:
> > > https://patchwork.openembedded.org/patch/66071/
> > >
> > > However, in the Yocto poky repository, I see commit
> > > 0221af0f4ee9e8bfb8796841bdf806e38bc600c6 which appears to be a
> > broken
> > > version of the above patch with the separate build_ext step not
> > > actually executed with the DISTUTILS_BUILD_EXT_ARGS parameters.
> > >
> > >
> > >
> > > You did not explain broken in which sense ?
> > >
> > >
> > >
> > > It is broken in the sense that: The separate build_ext step is not
> > > actually executed with the DISTUTILS_BUILD_EXT_ARGS parameters. The
> > > original patch submission contained:
> > >
> > >
> > >
> > >   STAGING_INCDIR=${STAGING_INCDIR} \
> > >
> > >   STAGING_LIBDIR=${STAGING_LIBDIR} \
> > >
> > >   BUILD_SYS=${BUILD_SYS} HOST_SYS=${HOST_SYS} \
> > >
> > > - ${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-
> native/${PYTHON_PN}
> > setup.py
> > > build ${DISTUTILS_BUILD_ARGS} || \
> > >
> > > + ${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-
> native/${PYTHON_PN}
> > > + setup.py
> > > \
> > >
> > > + build_ext --include-dirs
> > > ${STAGING_INCDIR}/${PYTHON_DIR}${PYTHON_ABI} \
> > >
> > > + --library-dirs ${STAGING_LIBCDIR}/${PYTHON_DIR} \
> > >
> > > + ${DISTUTILS_BUILD_EXT_ARGS} \
> > >
> > > + build ${DISTUTILS_BUILD_ARGS} || \
> > >
> > > + ${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-
> native/${PYTHON_PN}
> > > + setup.py
> > > build_ext ${DISTUTILS_BUILD_ARGS} || \
> > >
> > >   bbfatal "${PYTHON_PN} setup.py build_ext execution failed."
> > >
> > > }
> > >
> > >
> > >
> > > However that part of the patch is not present in commit
> > > 0221af0f4ee9e8bfb8796841bdf806e38bc600c6.
> > >
> >
> > IIRC there were some breakages with this but it was long time ago. Can
> > you appy this change and test it out ?
> 
> I tried applying the change manually. The Yocto do_compile step succeeded.
> But then the do_install step still failed. It seems that the do_install step
> (which runs setup.py install) still runs the setup.py build_ext step a second
> time, without the extra option I was trying to use.
> 
> I'm not familiar enough with the working of python3 setup.py to know why
> the install step re-runs the build_ext step a second time.

I wasn't able to find an elegant solution for DISTUTILS_BUILD_EXT_ARGS. I ended 
up getting a working python3-uvloop recipe a different way, using two patches 
to the setup.py.

I have posted to the uvloop project regarding this:

https://github.com/MagicStack/uvloop/issues/104

-- 
Craig McQueen

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Python recipes wanted?

2017-08-31 Thread Craig McQueen

I have made a number of recipes for Python packages, for my own use. Does 
meta-oe have an interest in any/all Python package recipe contributions, or 
ones that are considered more popular?

I have:

python3-aiohttp_2.2.3.bb
python3-aiohttp-jinja2_0.13.0.bb
python3-aiohttp-session_1.0.0.bb
python3-async-timeout_1.2.1.bb
python3-cobs_1.1.3.bb
python3-colorlog_2.10.0.bb
python3-configargparse_0.12.0.bb
python3-lru-dict_1.1.6.bb
python3-pycrypto_2.6.1.bb
python3-pyserial-asyncio_0.4.bb
python3-uvloop_0.8.0.bb
python3-yarl_0.11.0.bb

python-cobs_1.1.3.bb
python-lru-dict_1.1.6.bb

-- 
Craig McQueen

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-gplv2][PATCH] gmp_4.2.1: prevent calls to mpn_add_nc() if HAVE_NATIVE_mpn_sub_nc is false

2017-08-31 Thread Andre McCurdy

On Fri, Aug 25, 2017 at 5:50 PM, Andre McCurdy  wrote:
> When building for aarch64 (ie relying only on generic C code rather
> than asm) libgmp.so contains undefined references to __gmpn_add_nc
> and __gmpn_sub_nc which causes attempts to link with -lgmp to fail:
>
>  | .../usr/lib/libgmp.so: undefined reference to `__gmpn_sub_nc'
>  | .../usr/lib/libgmp.so: undefined reference to `__gmpn_add_nc'
>
> Solution based on a historical patch posted to the gmp mailing list:
>
>   https://gmplib.org/list-archives/gmp-discuss/2006-May/002344.html
>
> Signed-off-by: Andre McCurdy 
> ---

Ping.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Perforce fetcher ignores module and label

2017-08-31 Thread Andrew Bradford

Hi Katu,

On 08/28 17:43, Katu Txakur wrote:
> Thanks for looking at this. See my recipe below. I've left the bits related
> to systemd service but I don't think they matter for this. I'm using an old
> implementation of Perforce (2010) in case this matters. I've tried going
> back to the old perforce.py fetcher but I get a license error... do you
> know if it would be easy to revert to the old version in my bitbake folder
> until we make this work?

Sorry, I've been swamped this week and haven't been able to look into
this yet.  This coming weekend is a holiday weekend in the USA, too.
But I plan to look at this early next week, hope that's OK.

We should be able to create a patch series to revert my changes so you
can go back to the old perforce fetcher.  It might also be worth
investigating how to take the current perforce fetcher and enable some
of the use cases that you have (but we can do this after we successfully
revert).

I'll try to send a patch to you next week for the reverting.
Thanks,
Andrew

> DESCRIPTION = "Dummy recipe to fetch from Perforce"
> SECTION = "PerforceRecipes"
> LICENSE = "CLOSED"
> PR = "r0"
> 
> inherit cmake
> DEPENDS = "boost alsa-tools"
> 
> P4USER = "myuser"
> P4PASSWD = ""
> P4PORT = "192.168.1.55:1666"
> FETCHCMD_p4 = "/usr/local/bin/p4"
> 
> SRC_URI = " \
> p4://${P4USER}:${P4PASSWD}@myrepo/myfolder/...; \
> file://perforce-recipe.service \
> "
> SRCREV = "${AUTOREV}"
> S = "${WORKDIR}/p4"
> 
> do_install_append () {
> install -d ${D}${systemd_unitdir}/system
> install -m 0644 ../perforce-recipe.service ${D}${systemd_unitdir}/system
> }
> 
> NATIVE_SYSTEMD_SUPPORT = "1"
> SYSTEMD_PACKAGES = "perforce-recipe"
> SYSTEMD_SERVICE_${PN} = "perforce-recipe.service"
> 
> SYSTEMD_AUTO_ENABLE = "disable"
> 
> FILES_${PN} = "${systemd_unitdir} ${bindir}"
> 
> 
> 2017-08-28 15:27 GMT+01:00 Andrew Bradford :
> 
> > Hi Katu,
> >
> > On 08/28 08:56, Katu Txakur wrote:
> > > 2017-08-11 13:52 GMT+01:00 Andrew Bradford  > >:
> > > On 08/11 11:34, Katu Txakur wrote:
> > > > > 2017-08-07 12:17 GMT+01:00 Andrew Bradford <
> > and...@bradfordembedded.com
> > > > >:
> > > > > > On 08/02 10:28, Paul Eggleton wrote:
> > > > > > > On Wednesday, 2 August 2017 9:40:10 AM CEST Katu Txakur wrote:
> > > > > > > > I'm still having problems fetching from Perforce. Is there any
> > > > > > > > documentation based on the latest implementation of the
> > > > > > > > poky/bitbake/lib/bb/fetch2/perforce.py file?
> > > > > >
> > > > > > There's some documentation now in the official Yocto Project
> > > > > > documentation location for bitbake fetchers [1].  Prior to my
> > changes
> > > > > > there was very little if any documentation, afaik.
> > > > > >
> > > > > > [1]: http://www.yoctoproject.org/docs/2.3.1/bitbake-user-
> > > > > > manual/bitbake-user-manual.html#perforce-fetcher
> > > > > >
> > > > > > > > 2017-07-25 10:05 GMT+01:00 Katu Txakur  > >:
> > > > > > > > > I'm upgrading a recipe that fetches the source code from
> > > > Perforce.
> > > > > > > > >
> > > > > > > > > The old recipe was:
> > > > > > > > >
> > > > > > > > > SRC_URI = " \
> > > > > > > > >   p4://${P4USER}:${P4PASSWD}:${P4HOST}:${P4PORT}@Depot/path/
> > pe
> > > > > > > > > rforce/...;module=local/path/relativeto/p4;label=${
> > P4CHANGELIST}
> > > > \
> > > > > > > > >   "
> > > > > > > > >
> > > > > > > > > With the new version of /lib/bb/fetch2/perforce.py, I had to
> > set
> > > > > > P4PORT
> > > > > > > > > outside SRC_URI, leaving the recipe with:
> > > > > > > > >
> > > > > > > > > SRC_URI = " \
> > > > > > > > >   p4://${P4USER}:${P4PASSWD}@Depot/path/perforce/...;module=
> > > > > > > > > local/path/relativeto/p4;label=${P4CHANGELIST} \
> > > > > > > > >   "
> > > > > > > > >
> > > > > > > > > The Perforce fetcher kind of works, but it seems to be
> > ignoring
> > > > the
> > > > > > > > > "module" and the "label" attributes. After reading the Python
> > > > script
> > > > > > I can
> > > > > > > > > see that after the "@", only the substring before the first
> > ";"
> > > > is
> > > > > > used.
> > > > > >
> > > > > > Sorry for not making the label change more clear, but you should be
> > > > able
> > > > > > to simply set SRCREV="labelname" and have the functionality you
> > desire.
> > > > > > However, we don't use labels very often internally, so the use of
> > > > labels
> > > > > > in SRCREV isn't tested that often by me.
> > > > > >
> > > > >
> > > > > I don't use labels that much either, however, I used to be able to
> > write
> > > > > the changeslist number as a label and it would
> > > > > fetch the code for that changelist. This doesn't work using SRCREV =
> > > > > "changelistnumber"
> > > >
> > > > This does work for me using oe-core morty branch and bitbake
> > > > 1.32 which is the versions where these changes were first applied and
> > > > where I did my testing.
> > > >
> > > > Like I have a recipe which I

[yocto] Building Custom Python 3 Packages

2017-08-31 Thread Seilis, Aaron

Hi,

I'm building a couple of custom Python 3 scripts+modules as part of the -native 
tools required to build a number of my embedded components. I'm having 
difficulties getting my recipe to build when I've run `devtool modify` but the 
build works fine in a regular build. The Python tools are stored in various Git 
repositories and use the typical setuptools infrastructure.

My recipe is roughly as follows:

> inherit setuptools3
>
> SUMMARY = "My tool"
> DESCRIPTION = "Description"
>
> SECTION = "devel/scripts"
> LICENSE = "CLOSED"
>
> SRC_URI = "my-URL"
> SRCREV = "git hash"
>
> S = "${WORKDIR}/git/"
> BBCLASSEXTEND = "native"

This builds fine when running Bitbake normally; the tool is built and can be 
used to build other components. However, when I run `devtool modify`, the ${S} 
variable gets set to my alternate source location but the ${B} variable remains 
under ${WORKDIR}. This causes the build to fail with the error:

> ERROR: mytool-native-1.3.5-r0 do_install: python3 setup.py install execution 
> failed.
> ERROR: mytool-native-1.3.5-r0 do_install: Function failed: do_install (log 
> file is located at 
> /.../build/tmp/work/x86_64-linux/mytool-native/1.3.5-r0/temp/log.do_install.39172)
> ERROR: Logfile of failure stored in: 
> /.../build/tmp/work/x86_64-linux/mytool-native/1.3.5-r0/temp/log.do_install.39172
> Log data follows:
> | DEBUG: Executing shell function do_install
> | /.../build/tmp/sysroots/x86_64-linux/usr/bin/python3-native/python3: can't 
> open file 'setup.py': [Errno 2] No such file or directory
> | ERROR: python3 setup.py install execution failed.
> ERROR: Function failed: do_install (log file is located at 
> /.../build/tmp/work/x86_64-linux/mytool-native/1.3.5-r0/temp/log.do_install.39172)
> ERROR: Task 0 
> (virtual:native:/.../sources/meta-myproject/recipes-tools/mytool/mytool_1.3.5.bb,
>  do_install) failed with exit code '1'

Looking at the build recipes for Python, shows that the do_compile() step for 
Python modules (with setuptools3) is:

>distutils3_do_compile() {
>if [ x86_64-linux != aarch64-WaveserverOS-linux ]; then
>SYS=wcs
>else
>SYS=aarch64-WaveserverOS-linux
>fi
>
> STAGING_INCDIR=/localdata/projects/waveserver/build/tmp/sysroots/wcs/usr/include
>  \
>
> STAGING_LIBDIR=/localdata/projects/waveserver/build/tmp/sysroots/wcs/usr/lib \
>BUILD_SYS=x86_64-linux HOST_SYS=${SYS} \
>
> /localdata/projects/waveserver/build/tmp/sysroots/x86_64-linux/usr/bin/python3-native/python3
>  setup.py \
>build  || \
>bbfatal_log "python3 setup.py build_ext execution failed."
>}

This clearly indicates that the issue is that the build is looking for setup.py 
in the ${B} location, but it is only present in the ${S} location when `devtool 
modify` has been run. I have tried setting ${B} to ${S} explicitly in the 
recipe, but this doesn't result in ${B} being changed when I run `bitbake -e 
mytool`. I could always copy ${S} to ${B} in the recipe, but that seems a bit 
hack-ish.

Did I miss something or is there another way that Python builds are intended to 
work?

Thanks,
Aaron
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [yocto-docs][PATCH] kernel-dev: fix typo

2017-08-31 Thread Andrea Galbusera

On Sun, Aug 13, 2017 at 4:29 PM, Andrea Galbusera  wrote:

> Signed-off-by: Andrea Galbusera 
> ---
>  documentation/kernel-dev/kernel-dev-advanced.xml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/documentation/kernel-dev/kernel-dev-advanced.xml
> b/documentation/kernel-dev/kernel-dev-advanced.xml
> index 0394e08..c7e5a3a 100644
> --- a/documentation/kernel-dev/kernel-dev-advanced.xml
> +++ b/documentation/kernel-dev/kernel-dev-advanced.xml
> @@ -867,7 +867,7 @@
>  When stored outside of the recipe-space, the kernel Metadata
>  files reside in a separate repository.
>  The OpenEmbedded build system adds the Metadata to the build
> as
> -a "ktype=meta" repository through the
> +a "type=kmeta" repository through the
>  SRC_URI
>  variable.
>  As an example, consider the following
> SRC_URI
> --
> 2.7.4
>
>
ping...

Just to check I'm not mistakenly using the wrong list/subject/workflow...
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-security][PATCH] fail2bin: Add new package

[yocto] [meta-security][PATCH] fail2bin: Add new package

Re: [yocto] [layerindex-web][PATCH v4] Asynchronous email notifications, task execution

Re: [yocto] Python recipes wanted?

[yocto] apt-key not found

Re: [yocto] Python module and build_ext args

[yocto] Python recipes wanted?

Re: [yocto] [meta-gplv2][PATCH] gmp_4.2.1: prevent calls to mpn_add_nc() if HAVE_NATIVE_mpn_sub_nc is false

Re: [yocto] Perforce fetcher ignores module and label

[yocto] Building Custom Python 3 Packages

Re: [yocto] [yocto-docs][PATCH] kernel-dev: fix typo

11 matches

Site Navigation

Mail list logo

Footer information