date:20170518

[yocto] [meta-security][PATCH] packagegroup-security-tpm-i2c: fix syntax

2017-05-18 Thread Peter Lei

Fix "ERROR: ExpansionError during parsing" when building with multilib.

Signed-off-by: Peter Lei 
---
 meta-tpm/recipes-core/packagegroup/packagegroup-security-tpm-i2c.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/meta-tpm/recipes-core/packagegroup/packagegroup-security-tpm-i2c.bb 
b/meta-tpm/recipes-core/packagegroup/packagegroup-security-tpm-i2c.bb
index d3d9ebc..2d93aca 100644
--- a/meta-tpm/recipes-core/packagegroup/packagegroup-security-tpm-i2c.bb
+++ b/meta-tpm/recipes-core/packagegroup/packagegroup-security-tpm-i2c.bb
@@ -10,7 +10,7 @@ PACKAGES = "packagegroup-security-tpm-i2c"
 SUMMARY_packagegroup-security-tpm-i2c = "Security TPM i2c support"
 RDEPENDS_packagegroup-security-tpm-i2c = " \
 ${@bb.utils.contains('MACHINE_FEATURES', 'tpm', 
'packagegroup-security-tpm', '', d)} \
-${@bb.utils.contains('MACHINE_FEATURES', 'tpm2', 
'packagegroup-security-tpm2, '', d)} \
+${@bb.utils.contains('MACHINE_FEATURES', 'tpm2', 
'packagegroup-security-tpm2', '', d)} \
 kernel-module-tpm-i2c-atmel \
 kernel-module-tpm-i2c-infineon \
 kernel-module-tpm-i2c-nuvoton \
-- 
2.9.4

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

[yocto] What can I share between projects?

2017-05-18 Thread Paul D. DeRocco

If I'm doing multiple unrelated Yocto based projects, and they use the
same version of Yocto, and the same metadata (except for my own layers),
am I right in assuming that I can share everything in poky, downloads, and
sstate-cache, and I only need separate build directories? (I normally put
downloads and sstate-cache next to my build directory, rather than inside
it.)

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com

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

Re: [yocto] [poky/classes] [PATCH] new alternatesrc.bbclass

2017-05-18 Thread Koehler, Yannick (HPN Aruba)

The alternatesrc is also way faster than managing local layer just to 
re-specify the git location.

The ALTERNATESRC can be automatically calulated such as

  inherit alternatesrc

  ALTERNATESRC="$YOURROOT/$P"

As such all recipe looks the same, and if you do git clone URI $YOURROOT/$P 
locally, the yocto build use your code, you fix, commit, push, then you can 
keep the folder there or you can remove it.  If you do remove it, next build 
use your git URI as before and you are testing that your previous push made it 
to the server.

Way faster than changing recipe in private layer or not.

In any case, the idea of this system is to be flexible and sharing it with you 
should enable other to gain development speed from that.

From: yocto-boun...@yoctoproject.org  on behalf 
of Koehler, Yannick (HPN Aruba)
Sent: May 18, 2017 6:12:13 PM
To: Joshua Watt
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] [poky/classes] [PATCH] new alternatesrc.bbclass

Sounds great, but I have to deal with à team of buildroot beliver, as such, 
askibg dev to setup their own layrr manually is too complexe for them.  With my 
solution they do not have to do anything on their setup.

Get Outlook for iOS

From: Joshua Watt 
Sent: Thursday, May 18, 2017 5:37:29 PM
To: Koehler, Yannick (HPN Aruba)
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] [poky/classes] [PATCH] new alternatesrc.bbclass

On Thu, May 18, 2017 at 1:11 PM, Koehler, Yannick (HPN Aruba)
 wrote:
> In our environment, we have package that are store inside git in their own 
> repo.  Using SRC_URI we fetch the code and build it from the git repo itself 
> and all is fine.  When developer wants to change the content of the package, 
> they had to clone, change, commit, push and only then they were able to test 
> because yocto recipe clone/fetch from the git server only.
FWIW, our devs keep their own private bitbake layers that they add
locally to bblayers.conf. In these layers they add .bbappends that
override the SRC_URI for recipes they are interested in to point at
local repositories.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [poky/classes] [PATCH] new alternatesrc.bbclass

2017-05-18 Thread Koehler, Yannick (HPN Aruba)

Sounds great, but I have to deal with à team of buildroot beliver, as such, 
askibg dev to setup their own layrr manually is too complexe for them.  With my 
solution they do not have to do anything on their setup.

Get Outlook for iOS

From: Joshua Watt 
Sent: Thursday, May 18, 2017 5:37:29 PM
To: Koehler, Yannick (HPN Aruba)
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] [poky/classes] [PATCH] new alternatesrc.bbclass

On Thu, May 18, 2017 at 1:11 PM, Koehler, Yannick (HPN Aruba)
 wrote:
> In our environment, we have package that are store inside git in their own 
> repo.  Using SRC_URI we fetch the code and build it from the git repo itself 
> and all is fine.  When developer wants to change the content of the package, 
> they had to clone, change, commit, push and only then they were able to test 
> because yocto recipe clone/fetch from the git server only.
FWIW, our devs keep their own private bitbake layers that they add
locally to bblayers.conf. In these layers they add .bbappends that
override the SRC_URI for recipes they are interested in to point at
local repositories.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-xilinx] Trying to build xen-guest-image-minimal

2017-05-18 Thread Alistair Francis

On Thu, May 18, 2017 at 12:48 AM, Pello Heriz
 wrote:
> Hi Alistair,
>
> I have deleted the two lines that you have told me:
>
> -IMAGE_INSTALL += "${@bb.utils.contains('DISTRO_FEATURES', 'x11', '
> xf86-video-fbdev', '', d)}"
> -IMAGE_INSTALL += "${@bb.utils.contains('DISTRO_FEATURES', 'x11', '
> xf86-video-vesa', '', d)}"
>
> Anyway, now I'm getting another problem:
>
> generalelectric@mlan11214m117linux:/opt/yocto_GE/poky/master/build$ bitbake
> xen-guest-image-minimal
> Loading cache: 100% || Time:
> 0:00:00
> Loaded 2865 entries from dependency cache.
> Parsing recipes: 100% |##| Time:
> 0:00:01
> Parsing of 2097 .bb files complete (2079 cached, 18 parsed). 2881 targets,
> 198 skipped, 0 masked, 0 errors.
> WARNING: No recipes available for:
>
> /opt/yocto_GE/poky/master/meta-petalinux/recipes-devtools/python/python-smartpm_%.bbappend
> NOTE: Resolving any missing task queue dependencies
> ERROR: Nothing RPROVIDES 'nativesdk-smartpm' (but
> /opt/yocto_GE/poky/master/meta/recipes-core/meta/buildtools-tarball.bb
> RDEPENDS on or otherwise requires it)
> NOTE: Runtime target 'nativesdk-smartpm' is unbuildable, removing...
> Missing or unbuildable dependency chain was: ['nativesdk-smartpm']
> ERROR: Required build target 'xen-guest-image-minimal' has no buildable
> providers.
> Missing or unbuildable dependency chain was: ['xen-guest-image-minimal',
> 'buildtools-tarball', 'nativesdk-smartpm']
>
> Summary: There was 1 WARNING message shown.
> Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
> generalelectric@mlan11214m117linux:/opt/yocto_GE/poky/master/build$
>
> Do you know how can I solve this issue?

Strange, I haven't seen this before. Are you sure you have all the
layers that you need and that the versions match?

Thanks,

Alistair

>
> Best regards,
> Pello
>
>
> 2017-05-17 17:16 GMT+02:00 Alistair Francis :
>>
>> On Wed, May 17, 2017 at 12:37 AM, Pello Heriz
>>  wrote:
>> > Hi all,
>> >
>> > I'm trying to build a xen-guest-image-minimal, but I have the next
>> > error:
>> >
>> > generalelectric@mlan11214m117linux:/opt/yocto_GE/poky/master/build$
>> > bitbake
>> > xen-guest-image-minimal
>> > Loading cache: 100% || Time:
>> > 0:00:01
>> > Loaded 2865 entries from dependency cache.
>> > Parsing recipes: 100% |##| Time:
>> > 0:00:01
>> > Parsing of 2097 .bb files complete (2080 cached, 17 parsed). 2881
>> > targets,
>> > 198 skipped, 0 masked, 0 errors.
>> > WARNING: No recipes available for:
>> >
>> >
>> > /opt/yocto_GE/poky/master/meta-petalinux/recipes-devtools/python/python-smartpm_%.bbappend
>> > NOTE: Resolving any missing task queue dependencies
>> > ERROR: Nothing RPROVIDES 'xf86-video-vesa' (but
>> >
>> > /opt/yocto_GE/poky/master/meta-virtualization/recipes-extended/images/xen-guest-image-minimal.bb
>> > RDEPENDS on or otherwise requires it)
>> > ERROR: xf86-video-vesa was skipped: incompatible with host
>> > aarch64-poky-linux (not in COMPATIBLE_HOST)
>> > NOTE: Runtime target 'xf86-video-vesa' is unbuildable, removing...
>> > Missing or unbuildable dependency chain was: ['xf86-video-vesa']
>> > ERROR: Required build target 'xen-guest-image-minimal' has no buildable
>> > providers.
>> > Missing or unbuildable dependency chain was: ['xen-guest-image-minimal',
>> > 'xf86-video-vesa']
>> >
>> > Summary: There was 1 WARNING message shown.
>> > Summary: There were 2 ERROR messages shown, returning a non-zero exit
>> > code.
>> >
>> > As you can see next, this requiring file is in the meta directory so I
>> > don't
>> > know why I'm getting the issue.
>> >
>> > generalelectric@mlan11214m117linux:/opt/yocto_GE/poky/master/build$ cd
>> > ../meta/recipes-graphics/xorg-driver/
>> >
>> > generalelectric@mlan11214m117linux:/opt/yocto_GE/poky/master/meta/recipes-graphics/xorg-driver$
>> > ls
>> > xf86-input-evdev_2.10.5.bb xf86-video-omap_0.4.5.bb
>> > xf86-input-keyboard_1.9.0.bb   xf86-video-omapfb
>> > xf86-input-libinput_0.24.0.bb  xf86-video-omapfb_git.bb
>> > xf86-input-mouse_1.9.2.bb  xf86-video-vesa_2.3.4.bb
>> > xf86-input-synaptics_1.9.0.bb  xf86-video-vmware
>> > xf86-input-vmmouse_13.1.0.bb   xf86-video-vmware_13.2.1.bb
>> > xf86-video-cirrus_1.5.3.bb xorg-driver-common.inc
>> > xf86-video-fbdev_0.4.4.bb  xorg-driver-input.inc
>> > xf86-video-intel   xorg-driver-video.inc
>> > xf86-video-intel_git.bb
>> >
>> > generalelectric@mlan11214m117linux:/opt/yocto_GE/poky/master/meta/recipes-graphics/xorg-driver$
>> >
>> > Can any body help me with this problem?
>>
>> It looks like this should fix your problem:
>>
>> diff --git a/recipes-extended/images/xen-guest-image-minimal.bb
>> b/recipes-extended/images/xen-guest-image-minimal.bb
>> index ab7e92c..0143867 100644
>> ---

Re: [yocto] Trying to build a xen-image-minimal with petalinux v2016.4

2017-05-18 Thread Alistair Francis

On Thu, May 18, 2017 at 1:08 AM, Pello Heriz
 wrote:
> Hi all,
>
> I'm trying to build a xen-image-minimal using petalinux v2016.4 following
> the steps that are given in the ug1144 documentation. Anyway, when it starts
> to execute the bitbake, it shows the next errors making the building
> impossible:
>
> generalelectric@mlan11214m117linux:/opt/xen_test$ petalinux-build -c
> xen-image-minimal
> [INFO] building xen-image-minimal
> [INFO] sourcing bitbake
> INFO: bitbake xen-image-minimal
> Loading cache: 100% || ETA:
> 00:00:00
> Loaded 2940 entries from dependency cache.
> Parsing recipes: 100% |##| Time:
> 00:00:04
> Parsing of 2327 .bb files complete (2291 cached, 36 parsed). 2942 targets,
> 195 skipped, 0 masked, 0 errors.
> NOTE: Resolving any missing task queue dependencies
> NOTE: Preparing RunQueue
> NOTE: Checking sstate mirror object availability (for 320 objects)
> NOTE: Executing SetScene Tasks
> NOTE: Executing RunQueue Tasks
> WARNING: xen-4.7.0+gitAUTOINC+b49f2bffb7-r0 do_fetch: Failed to fetch URL
> git://github.com/Xilinx/xen.git;protocol=https, attempting MIRRORS if
> available
> WARNING: libglu-2_9.0.0-0 do_fetch: Failed to fetch URL
> ftp://ftp.freedesktop.org/pub/mesa/glu/glu-9.0.0.tar.bz2, attempting MIRRORS
> if available
> ERROR: xen-4.7.0+gitAUTOINC+b49f2bffb7-r0 do_fetch: Fetcher failure: Unable
> to find revision b49f2bffb7fb64eb8e9835161afeaca642ad0bac in branch master
> even from upstream
> ERROR: xen-4.7.0+gitAUTOINC+b49f2bffb7-r0 do_fetch: Function failed: Fetcher
> failure for URL: 'git://github.com/Xilinx/xen.git;protocol=https'. Unable to
> fetch URL from any source.
> ERROR: Logfile of failure stored in:
> /opt/xen_test/build/tmp/work/aarch64-xilinx-linux/xen/4.7.0+gitAUTOINC+b49f2bffb7-r0/temp/log.do_fetch.6468
> ERROR: Task 345
> (/opt/petalinux_2016.4/components/yocto/source/aarch64/layers/meta-petalinux/recipes-extended/xen/xen_4.7.0.bb,
> do_fetch) failed with exit code '1'
> NOTE: Tasks Summary: Attempted 2437 tasks of which 2421 didn't need to be
> rerun and 1 failed.
> Waiting for 0 running tasks to finish:

This is strange, it looks like the commit doesn't exist, but it does
exist. I can see it here:
https://github.com/Xilinx/xen/commit/b49f2bffb7fb64eb8e9835161afeaca642ad0bac

Do you have branch=none (or something like that) in the recipe?

Thanks,

Alistair

>
> Summary: 1 task failed:
>
> /opt/petalinux_2016.4/components/yocto/source/aarch64/layers/meta-petalinux/recipes-extended/xen/xen_4.7.0.bb,
> do_fetch
> Summary: There were 2 WARNING messages shown.
> Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
> ERROR: Failed to build xen-image-minimal
> webtalk failed:PetaLinux statistics:extra lines detected:notsent_nofile!
> webtalk failed:Failed to get PetaLinux usage statistics!
> generalelectric@mlan11214m117linux:/opt/xen_test$
>
> Can anybody tell me how can I solve the problem?
>
> Any answer will be welcome,
> Best regards,
> Pello
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [poky/classes] [PATCH] new alternatesrc.bbclass

2017-05-18 Thread Joshua Watt

On Thu, May 18, 2017 at 1:11 PM, Koehler, Yannick (HPN Aruba)
 wrote:
> In our environment, we have package that are store inside git in their own 
> repo.  Using SRC_URI we fetch the code and build it from the git repo itself 
> and all is fine.  When developer wants to change the content of the package, 
> they had to clone, change, commit, push and only then they were able to test 
> because yocto recipe clone/fetch from the git server only.
FWIW, our devs keep their own private bitbake layers that they add
locally to bblayers.conf. In these layers they add .bbappends that
override the SRC_URI for recipes they are interested in to point at
local repositories.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [[AUH][PATCH] 3/6] upgradehelper.py: Add ability to run UniverseUpdater over certain recipes

2017-05-18 Thread Aníbal Limón

[YOCTO #8962]

Signed-off-by: Aníbal Limón 
---
 upgradehelper.py | 31 +--
 1 file changed, 21 insertions(+), 10 deletions(-)

diff --git a/upgradehelper.py b/upgradehelper.py
index f7b87c6..6732fb2 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -655,9 +655,12 @@ class Updater(object):
 self.send_status_mail(statistics_summary)
 
 class UniverseUpdater(Updater):
-def __init__(self):
+def __init__(self, recipes=None):
 Updater.__init__(self, True, True)
 
+# to filter recipes in upgrade
+self.recipes = recipes
+
 # read history file
 self.history_file = os.path.join(get_build_dir(), "upgrade-helper", 
"history.uh")
 self.history = dict()
@@ -694,11 +697,16 @@ class UniverseUpdater(Updater):
 I(" Removing tmp directory ...")
 shutil.rmtree(os.path.join(get_build_dir(), "tmp"))
 
-def _check_upstream_versions(self, packages=[("universe", None, None)]):
+def _check_upstream_versions(self):
 I(" Fetching upstream version(s) ...")
 
+if self.recipes:
+recipe = " ".join(self.recipes)
+else:
+recipe = 'universe'
+
 try:
-self.bb.checkpkg(" ".join([p[0] for p in packages]))
+self.bb.checkpkg(recipe)
 except Error as e:
 for line in e.stdout.split('\n'):
 if line.find("ERROR: Task do_checkpkg does not exist") == 0:
@@ -876,16 +884,14 @@ if __name__ == "__main__":
 level=debug_levels[args.debug_level - 1])
 settings, maintainer_override = parse_config_file(args.config_file)
 
-if args.recipe == "all":
+recipes = args.recipe.split()
+
+if len(recipes) == 1 and recipes[0] == "all":
 updater = UniverseUpdater()
 updater.run()
-else:
-if not args.to_version:
-E(" For upgrade only one recipe you must specify --to_version\n")
-exit(1)
-
+elif len(recipes) == 1 and args.to_version:
 if not args.maintainer and args.send_emails:
-E(" For upgrade only one recipe and send email you must specify 
--maintainer\n")
+E(" For upgrade one recipe and send email you must specify 
--maintainer\n")
 exit(1)
 
 if not args.maintainer:
@@ -895,3 +901,8 @@ if __name__ == "__main__":
 pkg_list = [(args.recipe, args.to_version, args.maintainer)]
 updater = Updater(args.auto_mode, args.send_emails, 
args.skip_compilation)
 updater.run(pkg_list)
+else:
+updater = UniverseUpdater(recipes)
+updater.run()
+
+
-- 
2.1.4

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

[yocto] [[AUH][PATCH] 2/6] README: Update with the new layer settings.

2017-05-18 Thread Aníbal Limón

[YOCTO #8962]

Signed-off-by: Aníbal Limón 
---
 README | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/README b/README
index 1b73034..e6b0dc2 100644
--- a/README
+++ b/README
@@ -67,6 +67,12 @@ buildhistory=no
 testimage=no
 testimage_name=image-custom # defaults to core-image-sato
 
+# to enable upgrade recipes in a layer example for meta-intel
+layer_mode=False
+layer_name=meta-intel
+layer_dir=DIR/meta-intel
+layer_machines=intel-core2-32 intel-corei7-64 intel-quark
+
 --- snip ---
 
 3. Enable distrodata and supply appropriate additional metadata. For
-- 
2.1.4

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

[yocto] [[AUH][PATCH] 5/6] upgradehelper.py: Add layer name to upgrade email subject

2017-05-18 Thread Aníbal Limón

[YOCTO #8962]

Signed-off-by: Aníbal Limón 
---
 upgradehelper.py | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/upgradehelper.py b/upgradehelper.py
index 41f81c1..be4282f 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -440,7 +440,11 @@ class Updater(object):
 
 to_list = settings["status_recipients"].split()
 
-subject = "[AUH] Upgrade status: " + date.isoformat(date.today())
+if self.opts['layer_mode'] == 'yes':
+subject = "[AUH] Upgrade status %s: %s" \
+% (self.opts['layer_name'], date.isoformat(date.today()))
+else:
+subject = "[AUH] Upgrade status: " + date.isoformat(date.today())
 
 if self.statistics.total_attempted:
 self.email_handler.send_email(to_list, subject, statistics_summary)
-- 
2.1.4

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

[yocto] [[AUH][PATCH] 4/6] upgradehelper.py: Add support for sync layer master

2017-05-18 Thread Aníbal Limón

[YOCTO #8962]

Signed-off-by: Aníbal Limón 
---
 upgradehelper.py | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/upgradehelper.py b/upgradehelper.py
index 6732fb2..41f81c1 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -674,6 +674,10 @@ class UniverseUpdater(Updater):
 line.split(',')[4]]
 
 def _update_master(self):
+if self.opts['layer_mode'] == 'yes':
+I(" Sync poky master ...")
+self.poky_git.pull()
+
 I(" Drop all uncommited changes (including untracked) ...")
 self.git.reset_hard()
 self.git.clean_untracked()
@@ -683,7 +687,10 @@ class UniverseUpdater(Updater):
 self.git.delete_branch("upgrades")
 except Error:
 pass
-I(" Sync master ...")
+if self.opts['layer_mode'] == 'yes':
+I(" Sync %s master ..." % self.opts['layer_name'])
+else:
+I(" Sync poky master ...")
 self.git.pull()
 self.git.create_branch("upgrades")
 
-- 
2.1.4

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

[yocto] [[AUH][PATCH] 1/6] upgradehelper.py: Add support to load layer settings

2017-05-18 Thread Aníbal Limón

Those settings are to support layer recipe upgrades runs
into the AUH.

[YOCTO #8962]

Signed-off-by: Aníbal Limón 
---
 upgradehelper.py | 42 ++
 1 file changed, 34 insertions(+), 8 deletions(-)

diff --git a/upgradehelper.py b/upgradehelper.py
index df7d36d..f7b87c6 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -131,10 +131,6 @@ class Updater(object):
 def __init__(self, auto_mode=False, send_email=False, 
skip_compilation=False):
 build_dir = get_build_dir()
 
-self._make_dirs(build_dir)
-
-self._add_file_logger()
-
 self.bb = Bitbake(build_dir)
 
 try:
@@ -145,18 +141,43 @@ class Updater(object):
 E( " Bitbake output:\n%s" % (e.stdout))
 exit(1)
 
+self._set_options(auto_mode, send_email, skip_compilation)
+
+self._make_dirs(build_dir)
+
+self._add_file_logger()
+
 self.email_handler = Email(settings)
 self.statistics = Statistics()
-# XXX: assume that the poky directory is the first entry in the PATH
-self.git = Git(os.path.dirname(os.getenv('PATH', False).split(':')[0]))
 
+def _set_options(self, auto_mode, send_email, skip_compilation):
 self.opts = {}
+self.opts['layer_mode'] = settings.get('layer_mode', '')
+if self.opts['layer_mode'] == 'yes':
+def _layer_settings_error(setting):
+E(" In layer mode enable you need to specify %s.\n" % setting)
+exit(1)
+
+layer_settings = ('layer_name', 'layer_dir', 'layer_machines')
+for s in layer_settings:
+self.opts[s] = settings.get(s, '')
+if not self.opts[s]:
+_layer_settings_error(s)
+
+self.git = Git(self.opts['layer_dir'])
+self.poky_git = Git(os.path.dirname(os.getenv('PATH', 
False).split(':')[0]))
+self.opts['machines'] = self.opts['layer_machines'].split()
+else:
+# XXX: assume that the poky directory is the first entry in the 
PATH
+self.git = Git(os.path.dirname(os.getenv('PATH', 
False).split(':')[0]))
+self.poky_git = None
+self.opts['machines'] = settings.get('machines',
+'qemux86 qemux86-64 qemuarm qemumips qemuppc').split()
+
 self.opts['interactive'] = not auto_mode
 self.opts['send_email'] = send_email
 self.opts['author'] = "Upgrade Helper <%s>" % \
 settings.get('from', 'u...@not.set')
-self.opts['machines'] = settings.get('machines',
-'qemux86 qemux86-64 qemuarm qemumips qemuppc').split()
 self.opts['skip_compilation'] = skip_compilation
 self.opts['buildhistory'] = self._buildhistory_is_enabled()
 self.opts['testimage'] = self._testimage_is_enabled()
@@ -168,6 +189,11 @@ class Updater(object):
 self.uh_base_work_dir = settings.get('workdir', '')
 if not self.uh_base_work_dir:
 self.uh_base_work_dir = self.uh_dir
+if self.opts['layer_mode'] == 'yes':
+self.uh_base_work_dir = os.path.join(self.uh_base_work_dir,
+self.opts['layer_name'])
+if not os.path.exists(self.uh_base_work_dir):
+os.mkdir(self.uh_base_work_dir)
 self.uh_work_dir = os.path.join(self.uh_base_work_dir, "%s" % \
 datetime.now().strftime("%Y%m%d%H%M%S"))
 os.mkdir(self.uh_work_dir)
-- 
2.1.4

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

Re: [yocto] [poky/classes] [PATCH] new alternatesrc.bbclass

2017-05-18 Thread Khem Raj

On Thu, May 18, 2017 at 11:11 AM, Koehler, Yannick (HPN Aruba)
 wrote:
> In our environment, we have package that are store inside git in their own 
> repo.  Using SRC_URI we fetch the code and build it from the git repo itself 
> and all is fine.  When developer wants to change the content of the package, 
> they had to clone, change, commit, push and only then they were able to test 
> because yocto recipe clone/fetch from the git server only.

You could also let devs push into user branches ( joe/pull1 ) and use
EXTERNALSRC pointing to user branch
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [poky/classes] [PATCH] new alternatesrc.bbclass

2017-05-18 Thread Koehler, Yannick (HPN Aruba)

In our environment, we have package that are store inside git in their own 
repo.  Using SRC_URI we fetch the code and build it from the git repo itself 
and all is fine.  When developer wants to change the content of the package, 
they had to clone, change, commit, push and only then they were able to test 
because yocto recipe clone/fetch from the git server only.

We investigated externalsrc to use it so to build from a local folder, but then 
this required that all our packages be located locally on disk.  In turn, that 
cause other kind of headaches.  

I came up with the following solution "alternatesrc.bbclass" which is based on 
"externalsrc.bbclass" and do nothing unless a folder exists at the 
"ALTERNATESRC" location.  If a folder exists there, then the git SRC_URI is 
ignored and the do_fetch, do_unpack & do_patch are disabled.  The code located 
at the folder is used as is (no specific branch are checked out so to allow 
testing local change that have not been committed).

I am hoping to get feedback and comments, and maybe help someone else by 
sharing this.

Since this is my first contribution, I apologize if I didn't do it properly.

---
 meta/classes/alternatesrc.bbclass | 70 +++
 1 file changed, 70 insertions(+)
 create mode 100644 meta/classes/alternatesrc.bbclass

diff --git a/meta/classes/alternatesrc.bbclass 
b/meta/classes/alternatesrc.bbclass
new file mode 100644
index 00..13f85df851
--- /dev/null
+++ b/meta/classes/alternatesrc.bbclass
@@ -0,0 +1,72 @@
+# Copyright (C) 2017 Hewlett Packard Enterprise
+# Author: Yannick Koehler
+# Released under the MIT license (see COPYING.MIT for the terms)
+# Some code and influence taken from externalsrc.bbclass
+#
+# alternatesrc.bbclass enables use of an optionally existing source tree, 
usually external  
+# to the build system to build a piece of software rather than the usual 
fetch/unpack
+# process.
+#
+# To use, add alternatesrc to the global inherit and set ALTERNATESRC to point 
at the
+# directory you want to use containing the sources e.g. from local.conf for a 
recipe
+# called "myrecipe" you would do:
+#
+# INHERIT += "alternatesrc"
+# ALTERNATESRC_pn-myrecipe = "/path/to/my/source/tree"
+#
+
+ALTERNATESRC_COVEREDTASKS ?= "do_unpack do_fetch"
+
+python () {
+alternatesrc = d.getVar('ALTERNATESRC', True)
+
+if alternatesrc and os.path.isdir(alternatesrc):
+# Make it obvious that this is happening, since forgetting about it 
could lead to much confusion
+bb.note('NOTE: using alternate source tree %s' % 
(d.getVar('ALTERNATESRC', True)))
+
+d.setVar('S', alternatesrc)
+
+local_srcuri = []
+fetch = bb.fetch2.Fetch((d.getVar('SRC_URI', True) or '').split(), d)
+for url in fetch.urls:
+url_data = fetch.ud[url]
+parm = url_data.parm
+if (url_data.type == 'file' or
+'type' in parm and parm['type'] == 'kmeta'):
+local_srcuri.append(url)
+
+d.setVar('SRC_URI', ' '.join(local_srcuri))
+
+if '{SRCPV}' in d.getVar('PV', False):
+# Dummy value because the default function can't be called with 
blank SRC_URI
+d.setVar('SRCPV', '999')
+
+tasks = filter(lambda k: d.getVarFlag(k, "task", True), d.keys())
+
+for task in tasks:
+#if task.endswith("_setscene"):
+## sstate is never going to work for external source trees, 
disable it
+#bb.build.deltask(task, d)
+#else:
+# Since configure will likely touch ${S}, ensure only we lock so 
one task has access at a time
+d.appendVarFlag(task, "lockfiles", " ${S}/singletask.lock")
+
+# We do not want our source to be wiped out, ever (kernel.bbclass 
does this for do_clean)
+cleandirs = (d.getVarFlag(task, 'cleandirs', False) or '').split()
+setvalue = False
+for cleandir in cleandirs[:]:
+if d.expand(cleandir) == alternatesrc:
+cleandirs.remove(cleandir)
+setvalue = True
+if setvalue:
+d.setVarFlag(task, 'cleandirs', ' '.join(cleandirs))
+
+fetch_tasks = ['do_fetch', 'do_unpack']
+
+for task in d.getVar("ALTERNATESRC_COVEREDTASKS", True).split():
+if local_srcuri and task in fetch_tasks:
+continue
+bb.build.deltask(task, d)
+else:
+bb.note('NOTE: using git source tree, since local folder %s is 
inexistent' % (d.getVar('ALTERNATESRC', True)))
+}
-- 
2.12.0

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

Re: [yocto] Error: when reparsing

2017-05-18 Thread Khem Raj

On Thu, May 18, 2017 at 8:14 AM, Yuvarajesh Valleru  wrote:
> Hi,
>
> I was building a custom-linux-image. I succesfully build the image with the
> help of bitbake tool.
>
> When rebuilding the same image again, i was experiencing an error.
>
> ERROR: When reparsing .do_install, the basehash value changed from
> 3c2401cc61fce5eb899de19dbf78862f to 558516a74162944aff656a7d01321b12. The
> metadata is not deterministic and this needs to be fixed.
>
> Then i deleted the build/tmp and build/sstate, and again tried to rebuild.
> But Now I encountered with an another errors.
>
> Error:
> Matched in b manifest-i686-nativesdk-packagegroup-sdk-host.deploy-ipk
> Please verify which package should provide the above files.
> NOTE: Tasks Summary: Attempted 3172 tasks of which 2449 didn't need to be
> rerun and all succeeded.
>
> I deleted all the files in /deploy/ipk, build/sstate, build/tmp-glibc and
> also deploy/sdk/ for building a new image.
>
> Is there any alternative for rebuilding the image without the above errors
> and without deleting the file everytime.

if you are using DATE, TIME or combination of these
variables in metadata then this could cause
such issues.

>
> Best Regards,
> Rajesh
>
>
>
> --
> ___
> 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] Error: when reparsing

2017-05-18 Thread Yuvarajesh Valleru


Hi,

I was building a custom-linux-image. I succesfully build the image with 
the help of bitbake tool.


When rebuilding the same image again, i was experiencing an error.

/ERROR: When reparsing //.do_install, //the //basehash value changed 
from 3c2401cc61fce5eb899de19dbf78862f to //558516a74162944aff656a7d01321b12. The 
metadata is //not deterministic and this needs to be fixed. /Then i deleted the 
build/tmp and build/sstate, and again tried to rebuild. But Now I encountered with an 
another errors.

Error:
/Matched in b manifest-i686-nativesdk-packagegroup-sdk-host.deploy-ipk 
Please verify which package should provide the above files. NOTE: Tasks 
Summary: Attempted 3172 tasks of which 2449 didn't need to be rerun and 
all succeeded./


I deleted all the files in /deploy/ipk, build/sstate, build/tmp-glibc and also 
deploy/sdk/ for building a new image.

Is there any alternative for rebuilding the image without the above errors and 
without deleting the file everytime.

Best Regards,
Rajesh


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

Re: [yocto] [PATCH] mtree: add recipe

2017-05-18 Thread Christopher Larson

On Thu, May 18, 2017 at 12:22 AM,  wrote:

> From: Kai Kang 
>
> Add recipe mtree port from BSD. Add a patch to handle null return
> from getlogin.
>
> Signed-off-by: Kai Kang 
>

Exactly what layer are you aiming for this to go to? The list you sent it
to (yocto) doesn’t imply any particular layer..
-- 
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Senior Software Engineer, Mentor Graphics
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Problem using Subversion in Pyro

2017-05-18 Thread Alan Levy

OK, done that now. Thanks for your assistance

Alan

ALAN LEVY, Lead Consultant, Embedded Systems

Plextek Consulting, The Plextek Building, London Road, Great Chesterford, 
Saffron Walden, CB10 1NY, UK
T: +44 (0) 1799 533200E: alan.l...@plextek.com  W: www.plextek.com





-Original Message-
From: Alexander Kanavin [mailto:alexander.kana...@linux.intel.com] 
Sent: 18 May 2017 15:12
To: Alan Levy; yocto@yoctoproject.org
Subject: Re: [yocto] Problem using Subversion in Pyro

On 05/18/2017 05:02 PM, Alan Levy wrote:
> Here it is, certain names have been changed to protect the guilty. As 
> you can see at the bottom svn isn't on the path, so bitbake blows up 
> when it tries to evaluate SRCPV:
>
> ERROR: ExpansionError during parsing /my_recipe.bb
> | ETA:  0:00:01 Traceback (most recent call last):
> bb.data_smart.ExpansionError: Failure expanding variable SRCPV, 
> expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception
> FetchError: Fetcher failure: Fetch command export 
> DBUS_SESSION_BUS_ADDRESS="unix:abstract=/tmp/dbus-ykmscGFFM1"; export 
> SSH_AUTH_SOCK="/run/user/1000/keyring/ssh"; export 
> PATH="/home/user/project/yocto/build/tmp/sysroots-uninative/x86_64-lin
> ux/usr/bin:/home/user/project/yocto/poky/scripts:/home/user/project/yo
> cto/build/tmp/work/picozed_zynq7-poky-linux-gnueabi/my-recipe/fetchera
> voidrecurse-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi:/h
> ome/user/project/yocto/build/tmp/work/picozed_zynq7-poky-linux-gnueabi
> /my-recipe/fetcheravoidrecurse-r0/recipe-sysroot/usr/bin/crossscripts:
> /home/user/project/yocto/build/tmp/work/picozed_zynq7-poky-linux-gnuea
> bi/my-recipe/fetcheravoidrecurse-r0/recipe-sysroot-native/usr/sbin:/ho
> me/user/project/yocto/build/tmp/work/picozed_zynq7-poky-linux-gnueabi/
> my-recipe/fetcheravoidrecurse-r0/recipe-sysroot-native/usr/bin:/home/u
> ser/project/yocto/build/tmp/work/picozed_zynq7-poky-linux-gnueabi/my-r
> ecipe/fetcheravoidrecurse-r0/recipe-sysroot-native/sbin:/home/user/pro
> ject/yocto/build/tmp/work/picozed_zynq7-poky-linux-gnueabi/my-recipe/f
> etcheravoidrecurse-r0/recipe-sysroot-native/bin:/home/user/project/yoc
> to/poky/bitbake/bin:/home/user/project/yocto/build/tmp/hosttools";
> export HOME="/home/user"; LANG=C LC_ALL=C /usr/bin/env svn 
> --non-interactive --trust-server-cert log --limit 1 --no-auth-cache !
> http://server/path/my_module/ failed with exit code 127, output:
> /usr/bin/env: 'svn': No such file or directory
>

Right. This seems to happen way before the fetch task and so does require host 
svn, I guess you'll need to take it to bitbake mailing list. It works for git 
because we are using host's git for the same purpose.

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

Re: [yocto] Problem using Subversion in Pyro

2017-05-18 Thread Alexander Kanavin


On 05/18/2017 05:02 PM, Alan Levy wrote:

Here it is, certain names have been changed to protect the guilty. As
you can see at the bottom svn isn't on the path, so bitbake blows up
when it tries to evaluate SRCPV:

ERROR: ExpansionError during parsing /my_recipe.bb
| ETA:  0:00:01 Traceback (most recent call last):
bb.data_smart.ExpansionError: Failure expanding variable SRCPV,
expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception
FetchError: Fetcher failure: Fetch command export
DBUS_SESSION_BUS_ADDRESS="unix:abstract=/tmp/dbus-ykmscGFFM1"; export
SSH_AUTH_SOCK="/run/user/1000/keyring/ssh"; export
PATH="/home/user/project/yocto/build/tmp/sysroots-uninative/x86_64-linux/usr/bin:/home/user/project/yocto/poky/scripts:/home/user/project/yocto/build/tmp/work/picozed_zynq7-poky-linux-gnueabi/my-recipe/fetcheravoidrecurse-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi:/home/user/project/yocto/build/tmp/work/picozed_zynq7-poky-linux-gnueabi/my-recipe/fetcheravoidrecurse-r0/recipe-sysroot/usr/bin/crossscripts:/home/user/project/yocto/build/tmp/work/picozed_zynq7-poky-linux-gnueabi/my-recipe/fetcheravoidrecurse-r0/recipe-sysroot-native/usr/sbin:/home/user/project/yocto/build/tmp/work/picozed_zynq7-poky-linux-gnueabi/my-recipe/fetcheravoidrecurse-r0/recipe-sysroot-native/usr/bin:/home/user/project/yocto/build/tmp/work/picozed_zynq7-poky-linux-gnueabi/my-recipe/fetcheravoidrecurse-r0/recipe-sysroot-native/sbin:/home/user/project/yocto/build/tmp/work/picozed_zynq7-poky-linux-gnueabi/my-recipe/fetcheravoidrecurse-r0/recipe-sysroot-native/bin:/home/user/project/yocto/poky/

bitbake/bin:/home/user/project/yocto/build/tmp/hosttools";

export HOME="/home/user"; LANG=C LC_ALL=C /usr/bin/env svn
--non-interactive --trust-server-cert log --limit 1 --no-auth-cache !
http://server/path/my_module/ failed with exit code 127, output:
/usr/bin/env: 'svn': No such file or directory



Right. This seems to happen way before the fetch task and so does 
require host svn, I guess you'll need to take it to bitbake mailing 
list. It works for git because we are using host's git for the same purpose.


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

Re: [yocto] Problem using Subversion in Pyro

2017-05-18 Thread Alan Levy

Here it is, certain names have been changed to protect the guilty. As you can 
see at the bottom svn isn't on the path, so bitbake blows up when it tries to 
evaluate SRCPV:

ERROR: ExpansionError during parsing /my_recipe.bb   
| ETA:  0:00:01
Traceback (most recent call last):
bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression was 
${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher 
failure: Fetch command export 
DBUS_SESSION_BUS_ADDRESS="unix:abstract=/tmp/dbus-ykmscGFFM1"; export 
SSH_AUTH_SOCK="/run/user/1000/keyring/ssh"; export 
PATH="/home/user/project/yocto/build/tmp/sysroots-uninative/x86_64-linux/usr/bin:/home/user/project/yocto/poky/scripts:/home/user/project/yocto/build/tmp/work/picozed_zynq7-poky-linux-gnueabi/my-recipe/fetcheravoidrecurse-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi:/home/user/project/yocto/build/tmp/work/picozed_zynq7-poky-linux-gnueabi/my-recipe/fetcheravoidrecurse-r0/recipe-sysroot/usr/bin/crossscripts:/home/user/project/yocto/build/tmp/work/picozed_zynq7-poky-linux-gnueabi/my-recipe/fetcheravoidrecurse-r0/recipe-sysroot-native/usr/sbin:/home/user/project/yocto/build/tmp/work/picozed_zynq7-poky-linux-gnueabi/my-recipe/fetcheravoidrecurse-r0/recipe-sysroot-native/u
 
sr/bin:/home/user/project/yocto/build/tmp/work/picozed_zynq7-poky-linux-gnueabi/my-recipe/fetcheravoidrecurse-r0/recipe-sysroot-native/sbin:/home/user/project/yocto/build/tmp/work/picozed_zynq7-poky-linux-gnueabi/my-recipe/fetcheravoidrecurse-r0/recipe-sysroot-native/bin:/home/user/project/yocto/poky/bitbake/bin:/home/user/project/yocto/build/tmp/hosttools";
 export HOME="/home/user"; LANG=C LC_ALL=C /usr/bin/env svn --non-interactive 
--trust-server-cert log --limit 1 --no-auth-cache ! 
http://server/path/my_module/ failed with exit code 127, output:
/usr/bin/env: 'svn': No such file or directory

ALAN LEVY, Lead Consultant, Embedded Systems

Plextek Consulting, The Plextek Building, London Road, Great Chesterford, 
Saffron Walden, CB10 1NY, UK
T: +44 (0) 1799 533200E: alan.l...@plextek.com  W: www.plextek.com





-Original Message-
From: Alexander Kanavin [mailto:alexander.kana...@linux.intel.com] 
Sent: 18 May 2017 14:48
To: Alan Levy; yocto@yoctoproject.org
Subject: Re: [yocto] Problem using Subversion in Pyro

On 05/18/2017 04:46 PM, Alan Levy wrote:
> Just noticed the typo on my part - it's SRCPV that causes the problem, 
> not SRCREV. Apologies for the confusion; a maze of twisty little 
> variables, all alike

So how does it blow up? Can I see the python traceback?

You can also write a minimal recipe with a public svn repo; I can try to help, 
but I'd like you to provide a reproducible example :)

Alex

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

Re: [yocto] Problem using Subversion in Pyro

2017-05-18 Thread Alexander Kanavin


On 05/18/2017 04:46 PM, Alan Levy wrote:

Just noticed the typo on my part - it's SRCPV that causes the problem, not 
SRCREV. Apologies for the confusion; a maze of twisty little variables, all 
alike


So how does it blow up? Can I see the python traceback?

You can also write a minimal recipe with a public svn repo; I can try to 
help, but I'd like you to provide a reproducible example :)


Alex

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

Re: [yocto] Problem using Subversion in Pyro

2017-05-18 Thread Alan Levy

Just noticed the typo on my part - it's SRCPV that causes the problem, not 
SRCREV. Apologies for the confusion; a maze of twisty little variables, all 
alike

ALAN LEVY, Lead Consultant, Embedded Systems

Plextek Consulting, The Plextek Building, London Road, Great Chesterford, 
Saffron Walden, CB10 1NY, UK
T: +44 (0) 1799 533200E: alan.l...@plextek.com  W: www.plextek.com

-Original Message-
From: Alan Levy 
Sent: 18 May 2017 14:32
To: 'Alexander Kanavin'; yocto@yoctoproject.org
Subject: RE: [yocto] Problem using Subversion in Pyro

I want to assign SRCREV to PV, which is perfectly legitimate, so that I can 
capture the SVN revision number used to build the code. Here's a simple recipe 
which exhibits the problem:

DESCRIPTION = "Recipe to test SVN"
PACKAGE_ARCH = "${MACHINE_ARCH}"
LICENSE = "CLOSED"
PV = "${SRCPV}"
SRCREV = "${AUTOREV}"
SRC_URI = "svn://server/path;module=my_module"

If you comment out the line referring to SRCPV all is well, if you include it 
bitbake blows up, even if I just perform cleansstate.

ALAN LEVY, Lead Consultant, Embedded Systems

Plextek Consulting, The Plextek Building, London Road, Great Chesterford, 
Saffron Walden, CB10 1NY, UK
T: +44 (0) 1799 533200E: alan.l...@plextek.com  W: www.plextek.com





-Original Message-
From: Alexander Kanavin [mailto:alexander.kana...@linux.intel.com]
Sent: 18 May 2017 14:14
To: Alan Levy; yocto@yoctoproject.org
Subject: Re: [yocto] Problem using Subversion in Pyro

On 05/18/2017 04:04 PM, Alan Levy wrote:
> It does get built, and it apparently does get used to do the actual 
> fetching, just not for miscellaneous functions such as populating 
> SRCREV which rely on the svn executable being on the PATH. This 
> appears to be deliberate since there is a FETCHCMD_svn variable in 
> bitbake.conf. The simplest way for me to force an svn executable onto 
> PATH was to add it to HOSTTOOLS but that may not be what is really 
> intended.

SRCREV is supposed to be hardcoded in the recipe. What is the reason you need 
to use svn to set it? Can you show how it's specifically done in your recipe?


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

Re: [yocto] Install Torch7

2017-05-18 Thread Abayiz

Dear Fabien and Jussi, 

Thank you very much for your time and concern. 
After your suggestion I tried to find out all those packages installed by "bash 
install-deps". However I found that these deps are required to build JIT 
version of Lua, as mentioned on the official Torch website. 
So instead I used Lua 5.2 instead of JIT, which does not require to run "bash 
install-deps" first. And this time after I generated Torch recipe using devtool 
and tried to build it, the compilation proceeded to nearly 96%, then thows an 
error saying:
Could NOT find Wget (missing:  WGET_EXECUTABLE)
| -- Could NOT find MD5 (missing:  MD5_EXECUTABLE)
| -- curl found instead of wget 
:/home/abayiz/trunk/poky/build-hello/tmp/work/i586-poky-linux/torch/2.1devel+git999-r0/recipe-sysroot-native/usr/bin/curl
| CMake Error at exe/luajit-rocks/luarocks/CMakeLists.txt:77 (MESSAGE):
|   MD5 checker not found

However in the 'devtool' generated recipe file, I found this line:
# NOTE: unable to map the following CMake package dependencies: CUDA CUDNN BLAS 
ARM Torch SSE MD5 MAGMA LAPACK Readline
DEPENDS = "wget jpeg ncurses libpng"

Seems like wget is already set as built-time dependency but the system doesn't 
see it, as well as MD5. Do you have any suggestion for that?Thank you again. 
Best.  

On Thursday, May 18, 2017 4:17 PM, Fabien Lahoudere 
 wrote:

 On Thu, 2017-05-18 at 12:02 +, Abayiz wrote:
> Dear Fabien, 
> 
> Thank you very much for your reply. 
> No, I didn't try 'devtool edit-recipe torch' to add dependencies. Actually I 
> didn't know how to
> add them. Is there any way to directly call that .sh file there??
> Could you give me a minimal example to illustrate it? 

Usually we add build dependencies with DEPENDS = "..." and runtime dependencies 
with RDEPENDS =
"..."

So you need to check dependencies installed by "bash install-deps".
Can you list them? Maybe recipes exists in which case you have to add them to 
the variable described
above.

> 
> Thank you. 
> 
> 
> 
> On Thursday, May 18, 2017 10:17 AM, Fabien Lahoudere 
>  wrote:
> 
> 
> On Wed, 2017-05-17 at 08:37 +, Abayiz wrote:
> > Dear all, 
> > 
> > I'm quite new to Yocto, I've successfully built qemu and ran helloworld 
> > example on it. Now I'm
> > trying to install Torch 7 (https://github.com/torch/torch7) library. What I 
> > did is: 
> > 
> > devtool add torch https://github.com/torch/torch7.git
> > devtool build torch
> > 
> > But the build exits with error, in the attachment I share the log file with 
> > you. 
> > My host machine runs Ubuntu 16.04 LTS, and Torch7 is successfully running 
> > on it. The
> installation
> > of Torch first requires to run the 'bash install-deps' command on Ubuntu. 
> > My rough estimation is
> > that Yocto seems like cannot build those dependencies automatically. 
> > 
> > Could someone give any help on it? Installing Torch7 is very important to 
> > my project now, thank
> > you in advance. 
> > 
> 
> Do you try "devtool edit-recipe torch" to add dependencies to the recipe and 
> configure "cache
> variables" approprietly?
> 
> 
> > Best, 
> > Abayiz
> 
> > 
> -- 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
> 
> 
> 

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

Re: [yocto] Problem using Subversion in Pyro

2017-05-18 Thread Alan Levy

I want to assign SRCREV to PV, which is perfectly legitimate, so that I can 
capture the SVN revision number used to build the code. Here's a simple recipe 
which exhibits the problem:

DESCRIPTION = "Recipe to test SVN"
PACKAGE_ARCH = "${MACHINE_ARCH}"
LICENSE = "CLOSED"
PV = "${SRCPV}"
SRCREV = "${AUTOREV}"
SRC_URI = "svn://server/path;module=my_module"

If you comment out the line referring to SRCPV all is well, if you include it 
bitbake blows up, even if I just perform cleansstate.

ALAN LEVY, Lead Consultant, Embedded Systems

Plextek Consulting, The Plextek Building, London Road, Great Chesterford, 
Saffron Walden, CB10 1NY, UK
T: +44 (0) 1799 533200E: alan.l...@plextek.com  W: www.plextek.com





-Original Message-
From: Alexander Kanavin [mailto:alexander.kana...@linux.intel.com] 
Sent: 18 May 2017 14:14
To: Alan Levy; yocto@yoctoproject.org
Subject: Re: [yocto] Problem using Subversion in Pyro

On 05/18/2017 04:04 PM, Alan Levy wrote:
> It does get built, and it apparently does get used to do the actual 
> fetching, just not for miscellaneous functions such as populating 
> SRCREV which rely on the svn executable being on the PATH. This 
> appears to be deliberate since there is a FETCHCMD_svn variable in 
> bitbake.conf. The simplest way for me to force an svn executable onto 
> PATH was to add it to HOSTTOOLS but that may not be what is really 
> intended.

SRCREV is supposed to be hardcoded in the recipe. What is the reason you need 
to use svn to set it? Can you show how it's specifically done in your recipe?


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

Re: [yocto] Install Torch7

2017-05-18 Thread Fabien Lahoudere

On Thu, 2017-05-18 at 12:02 +, Abayiz wrote:
> Dear Fabien, 
> 
> Thank you very much for your reply. 
> No, I didn't try 'devtool edit-recipe torch' to add dependencies. Actually I 
> didn't know how to
> add them. Is there any way to directly call that .sh file there??
> Could you give me a minimal example to illustrate it? 

Usually we add build dependencies with DEPENDS = "..." and runtime dependencies 
with RDEPENDS =
"..."

So you need to check dependencies installed by "bash install-deps".
Can you list them? Maybe recipes exists in which case you have to add them to 
the variable described
above.


> 
> Thank you. 
> 
> 
> 
> On Thursday, May 18, 2017 10:17 AM, Fabien Lahoudere 
>  wrote:
> 
> 
> On Wed, 2017-05-17 at 08:37 +, Abayiz wrote:
> > Dear all, 
> > 
> > I'm quite new to Yocto, I've successfully built qemu and ran helloworld 
> > example on it. Now I'm
> > trying to install Torch 7 (https://github.com/torch/torch7) library. What I 
> > did is: 
> > 
> > devtool add torch https://github.com/torch/torch7.git
> > devtool build torch
> > 
> > But the build exits with error, in the attachment I share the log file with 
> > you. 
> > My host machine runs Ubuntu 16.04 LTS, and Torch7 is successfully running 
> > on it. The
> installation
> > of Torch first requires to run the 'bash install-deps' command on Ubuntu. 
> > My rough estimation is
> > that Yocto seems like cannot build those dependencies automatically. 
> > 
> > Could someone give any help on it? Installing Torch7 is very important to 
> > my project now, thank
> > you in advance. 
> > 
> 
> Do you try "devtool edit-recipe torch" to add dependencies to the recipe and 
> configure "cache
> variables" approprietly?
> 
> 
> > Best, 
> > Abayiz
> 
> > 
> -- 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
> 
> 
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Problem using Subversion in Pyro

2017-05-18 Thread Alexander Kanavin


On 05/18/2017 04:04 PM, Alan Levy wrote:

It does get built, and it apparently does get used to do the actual
fetching, just not for miscellaneous functions such as populating
SRCREV which rely on the svn executable being on the PATH. This
appears to be deliberate since there is a FETCHCMD_svn variable in
bitbake.conf. The simplest way for me to force an svn executable onto
PATH was to add it to HOSTTOOLS but that may not be what is really
intended.


SRCREV is supposed to be hardcoded in the recipe. What is the reason you 
need to use svn to set it? Can you show how it's specifically done in 
your recipe?



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

Re: [yocto] Problem using Subversion in Pyro

2017-05-18 Thread Alan Levy

It does get built, and it apparently does get used to do the actual fetching, 
just not for miscellaneous functions such as populating SRCREV which rely on 
the svn executable being on the PATH. This appears to be deliberate since there 
is a FETCHCMD_svn variable in bitbake.conf. The simplest way for me to force an 
svn executable onto PATH was to add it to HOSTTOOLS but that may not be what is 
really intended.

ALAN LEVY, Lead Consultant, Embedded Systems

Plextek Consulting, The Plextek Building, London Road, Great Chesterford, 
Saffron Walden, CB10 1NY, UK
T: +44 (0) 1799 533200E: alan.l...@plextek.com  W: www.plextek.com

-Original Message-
From: Alexander Kanavin [mailto:alexander.kana...@linux.intel.com] 
Sent: 18 May 2017 13:41
To: yocto@yoctoproject.org; Alan Levy
Subject: Re: [yocto] Problem using Subversion in Pyro

On 05/18/2017 02:40 PM, Alan Levy wrote:
> I have a recipe that fetches code from an SVN repository and uses 
> ${SRCPV} to obtain its version number. This works fine under Morty but 
> the recipe crashes out with an error under Pyro because it can't find 
> the SVN executable.
>
>
>
> Eventually I traced this down to the fact that SVN is missing from the 
> list of host apps defined in HOSTTOOLS in bitbake.conf. If I add an 
> assignment in local.conf to append svn to HOSTTOOLS all is well again.
>
>
>
> I think that this is almost certainly a bug but I thought I'd raise 
> the question here just in case it's really me doing something wrong.

There is a subversion recipe in oe-core, and it should be built (in the native 
variant) specifically for this purpose (base.bbclass):

 # Svn packages should DEPEND on subversion-native
 if scheme == "svn":
 needsrcrev = True
 d.appendVarFlag('do_fetch', 'depends', ' 
subversion-native:do_populate_sysroot')

BUT... we no longer have recipes in oe-core that fetch from svn:// so it does 
not get tested, and may well have regressed.

Can you check if it does get build, and whether the subversion binary gets 
installed into your recipe's sysroot?

Alex

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

Re: [yocto] Problem using Subversion in Pyro

2017-05-18 Thread Burton, Ross

On 18 May 2017 at 12:40, Alan Levy  wrote:

> Eventually I traced this down to the fact that SVN is missing from the
> list of host apps defined in HOSTTOOLS in bitbake.conf. If I add an
> assignment in local.conf to append svn to HOSTTOOLS all is well again.
>
>
As Alex says we typically use subversion-native as we can't rely on the
host subversion being new enough for some features we need.

Does your recipe fetch using svn:// in SRC_URI?  If so then it should have
svn in the sysroot already.  A minimal example would be useful.

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

Re: [yocto] Install Torch7

2017-05-18 Thread Jussi Kukkonen

On 18 May 2017 at 15:02, Abayiz  wrote:
> No, I didn't try 'devtool edit-recipe torch' to add dependencies.
Actually I didn't know how to add them. Is there any way to directly call
that .sh file there??

That shell script is very specific to a handful of distros. It will only
help you as a reference.

For the cache variables even the shell script wouldn't help: the project
just won't cross-compile on any distro unless you set those by hand.
I assume something like this in the recipe should help:
EXTRA_OECMAKE = "-D=  -D="
Experiment with one of the variables and see if you can make one of the
errors go away.

After that you will have to ensure each dependency is available at
build/run time as needed: Some of them will just require you to set DEPENDS
or RDEPENDS correctly, some may require you to write a recipe for the
dependency first.

> Could you give me a minimal example to illustrate it?

The documentation is extensive, I suggest you read the 5.3 section of the
dev-manual, especially 5.3.10. Dependencies:
http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#new-dependencies
and get back with specific questions if that doesn't help.

Based on a quick look I'd expect Torch to be quite tricky to package, be
prepared for new problems on the way.

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

Re: [yocto] Problem using Subversion in Pyro

2017-05-18 Thread Alexander Kanavin


On 05/18/2017 02:40 PM, Alan Levy wrote:

I have a recipe that fetches code from an SVN repository and uses
${SRCPV} to obtain its version number. This works fine under Morty but
the recipe crashes out with an error under Pyro because it can’t find
the SVN executable.



Eventually I traced this down to the fact that SVN is missing from the
list of host apps defined in HOSTTOOLS in bitbake.conf. If I add an
assignment in local.conf to append svn to HOSTTOOLS all is well again.



I think that this is almost certainly a bug but I thought I’d raise the
question here just in case it’s really me doing something wrong.


There is a subversion recipe in oe-core, and it should be built (in the 
native variant) specifically for this purpose (base.bbclass):


# Svn packages should DEPEND on subversion-native
if scheme == "svn":
needsrcrev = True
d.appendVarFlag('do_fetch', 'depends', ' 
subversion-native:do_populate_sysroot')


BUT... we no longer have recipes in oe-core that fetch from svn:// so it 
does not get tested, and may well have regressed.


Can you check if it does get build, and whether the subversion binary 
gets installed into your recipe's sysroot?


Alex

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

[yocto] Problem using Subversion in Pyro

2017-05-18 Thread Alan Levy

I have a recipe that fetches code from an SVN repository and uses ${SRCPV} to 
obtain its version number. This works fine under Morty but the recipe crashes 
out with an error under Pyro because it can't find the SVN executable.

Eventually I traced this down to the fact that SVN is missing from the list of 
host apps defined in HOSTTOOLS in bitbake.conf. If I add an assignment in 
local.conf to append svn to HOSTTOOLS all is well again.

I think that this is almost certainly a bug but I thought I'd raise the 
question here just in case it's really me doing something wrong.
ALAN LEVY
Lead Consultant, Embedded Systems

Tel > +44 (0) 1799 533200
Email > alan.l...@plextek.com

[http://www.plextek.com/wp-content/uploads/Footer-AlanLevy.jpg]
[http://www.plextek.com/wp-content/uploads/2016/04/Plextek-LOGO-for-email.jpg]

www.plextek.com
The Plextek Building, London Road, Great Chesterford, Saffron Walden, CB10 1NY, 
UK

Plextek is the trading name of Plextek Services Ltd. Registered in England and 
Wales, no. 09826669


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

[yocto] Trying to build a xen-image-minimal with petalinux v2016.4

2017-05-18 Thread Pello Heriz

Hi all,

I'm trying to build a xen-image-minimal using petalinux v2016.4 following
the steps that are given in the ug1144 documentation. Anyway, when it
starts to execute the bitbake, it shows the next errors making the building
impossible:

generalelectric@mlan11214m117linux:/opt/xen_test$ petalinux-build -c
xen-image-minimal
[INFO] building xen-image-minimal
[INFO] sourcing bitbake
INFO: bitbake xen-image-minimal
Loading cache: 100% || ETA:
00:00:00
Loaded 2940 entries from dependency cache.
Parsing recipes: 100% |##| Time:
00:00:04
Parsing of 2327 .bb files complete (2291 cached, 36 parsed). 2942 targets,
195 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
NOTE: Preparing RunQueue
NOTE: Checking sstate mirror object availability (for 320 objects)
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
WARNING: xen-4.7.0+gitAUTOINC+b49f2bffb7-r0 do_fetch: Failed to fetch URL
git://github.com/Xilinx/xen.git;protocol=https, attempting MIRRORS if
available
WARNING: libglu-2_9.0.0-0 do_fetch: Failed to fetch URL
ftp://ftp.freedesktop.org/pub/mesa/glu/glu-9.0.0.tar.bz2, attempting
MIRRORS if available
ERROR: xen-4.7.0+gitAUTOINC+b49f2bffb7-r0 do_fetch: Fetcher failure: Unable
to find revision b49f2bffb7fb64eb8e9835161afeaca642ad0bac in branch master
even from upstream
ERROR: xen-4.7.0+gitAUTOINC+b49f2bffb7-r0 do_fetch: Function failed:
Fetcher failure for URL: 'git://github.com/Xilinx/xen.git;protocol=https'.
Unable to fetch URL from any source.
ERROR: Logfile of failure stored in:
/opt/xen_test/build/tmp/work/aarch64-xilinx-linux/xen/4.7.0+gitAUTOINC+b49f2bffb7-r0/temp/log.do_fetch.6468
ERROR: Task 345
(/opt/petalinux_2016.4/components/yocto/source/aarch64/layers/meta-petalinux/recipes-extended/xen/
xen_4.7.0.bb, do_fetch) failed with exit code '1'
NOTE: Tasks Summary: Attempted 2437 tasks of which 2421 didn't need to be
rerun and 1 failed.
Waiting for 0 running tasks to finish:

Summary: 1 task failed:

/opt/petalinux_2016.4/components/yocto/source/aarch64/layers/meta-petalinux/recipes-extended/xen/
xen_4.7.0.bb, do_fetch
Summary: There were 2 WARNING messages shown.
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
ERROR: Failed to build xen-image-minimal
webtalk failed:PetaLinux statistics:extra lines detected:notsent_nofile!
webtalk failed:Failed to get PetaLinux usage statistics!
generalelectric@mlan11214m117linux:/opt/xen_test$

Can anybody tell me how can I solve the problem?

Any answer will be welcome,
Best regards,
Pello
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-xilinx] Trying to build xen-guest-image-minimal

2017-05-18 Thread Pello Heriz

Hi Alistair,

I have deleted the two lines that you have told me:

-IMAGE_INSTALL += "${@bb.utils.contains('DISTRO_FEATURES', 'x11', '
xf86-video-fbdev', '', d)}"
-IMAGE_INSTALL += "${@bb.utils.contains('DISTRO_FEATURES', 'x11', '
xf86-video-vesa', '', d)}"

Anyway, now I'm getting another problem:

generalelectric@mlan11214m117linux:/opt/yocto_GE/poky/master/build$ bitbake
xen-guest-image-minimal
Loading cache: 100% || Time:
0:00:00
Loaded 2865 entries from dependency cache.
Parsing recipes: 100% |##| Time:
0:00:01
Parsing of 2097 .bb files complete (2079 cached, 18 parsed). 2881 targets,
198 skipped, 0 masked, 0 errors.
WARNING: No recipes available for:

/opt/yocto_GE/poky/master/meta-petalinux/recipes-devtools/python/python-smartpm_%.bbappend
NOTE: Resolving any missing task queue dependencies
ERROR: Nothing RPROVIDES 'nativesdk-smartpm' (but
/opt/yocto_GE/poky/master/meta/recipes-core/meta/buildtools-tarball.bb
RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'nativesdk-smartpm' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['nativesdk-smartpm']
ERROR: Required build target 'xen-guest-image-minimal' has no buildable
providers.
Missing or unbuildable dependency chain was: ['xen-guest-image-minimal',
'buildtools-tarball', 'nativesdk-smartpm']

Summary: There was 1 WARNING message shown.
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
generalelectric@mlan11214m117linux:/opt/yocto_GE/poky/master/build$

Do you know how can I solve this issue?

Best regards,
Pello


2017-05-17 17:16 GMT+02:00 Alistair Francis :

> On Wed, May 17, 2017 at 12:37 AM, Pello Heriz
>  wrote:
> > Hi all,
> >
> > I'm trying to build a xen-guest-image-minimal, but I have the next error:
> >
> > generalelectric@mlan11214m117linux:/opt/yocto_GE/poky/master/build$
> bitbake
> > xen-guest-image-minimal
> > Loading cache: 100% || Time:
> > 0:00:01
> > Loaded 2865 entries from dependency cache.
> > Parsing recipes: 100% |##| Time:
> > 0:00:01
> > Parsing of 2097 .bb files complete (2080 cached, 17 parsed). 2881
> targets,
> > 198 skipped, 0 masked, 0 errors.
> > WARNING: No recipes available for:
> >
> > /opt/yocto_GE/poky/master/meta-petalinux/recipes-devtools/python/python-
> smartpm_%.bbappend
> > NOTE: Resolving any missing task queue dependencies
> > ERROR: Nothing RPROVIDES 'xf86-video-vesa' (but
> > /opt/yocto_GE/poky/master/meta-virtualization/recipes-extended/images/
> xen-guest-image-minimal.bb
> > RDEPENDS on or otherwise requires it)
> > ERROR: xf86-video-vesa was skipped: incompatible with host
> > aarch64-poky-linux (not in COMPATIBLE_HOST)
> > NOTE: Runtime target 'xf86-video-vesa' is unbuildable, removing...
> > Missing or unbuildable dependency chain was: ['xf86-video-vesa']
> > ERROR: Required build target 'xen-guest-image-minimal' has no buildable
> > providers.
> > Missing or unbuildable dependency chain was: ['xen-guest-image-minimal',
> > 'xf86-video-vesa']
> >
> > Summary: There was 1 WARNING message shown.
> > Summary: There were 2 ERROR messages shown, returning a non-zero exit
> code.
> >
> > As you can see next, this requiring file is in the meta directory so I
> don't
> > know why I'm getting the issue.
> >
> > generalelectric@mlan11214m117linux:/opt/yocto_GE/poky/master/build$ cd
> > ../meta/recipes-graphics/xorg-driver/
> > generalelectric@mlan11214m117linux:/opt/yocto_
> GE/poky/master/meta/recipes-graphics/xorg-driver$
> > ls
> > xf86-input-evdev_2.10.5.bb xf86-video-omap_0.4.5.bb
> > xf86-input-keyboard_1.9.0.bb   xf86-video-omapfb
> > xf86-input-libinput_0.24.0.bb  xf86-video-omapfb_git.bb
> > xf86-input-mouse_1.9.2.bb  xf86-video-vesa_2.3.4.bb
> > xf86-input-synaptics_1.9.0.bb  xf86-video-vmware
> > xf86-input-vmmouse_13.1.0.bb   xf86-video-vmware_13.2.1.bb
> > xf86-video-cirrus_1.5.3.bb xorg-driver-common.inc
> > xf86-video-fbdev_0.4.4.bb  xorg-driver-input.inc
> > xf86-video-intel   xorg-driver-video.inc
> > xf86-video-intel_git.bb
> > generalelectric@mlan11214m117linux:/opt/yocto_
> GE/poky/master/meta/recipes-graphics/xorg-driver$
> >
> > Can any body help me with this problem?
>
> It looks like this should fix your problem:
>
> diff --git a/recipes-extended/images/xen-guest-image-minimal.bb
> b/recipes-extended/images/xen-guest-image-minimal.bb
> index ab7e92c..0143867 100644
> --- a/recipes-extended/images/xen-guest-image-minimal.bb
> +++ b/recipes-extended/images/xen-guest-image-minimal.bb
> @@ -7,9 +7,6 @@ IMAGE_INSTALL += " \
>  ${@bb.utils.contains('MACHINE_FEATURES', 'acpi',
> 'kernel-module-xen-acpi-processor', '', d)} \
>  "
>
> -IMAGE_INSTALL += "${@bb.utils.contains('DISTRO_FEATURES', 'x11', '
> xf86-video-fbdev', '', d)}"
> -IMAGE_INSTALL +=

[yocto] [meta-security][PATCH] Add recipe mtree

2017-05-18 Thread kai.kang

From: Kai Kang 

Commit at:
https://github.com/parr0tr1ver/meta-security/commit/2955017982dc733233267e955295ff40b11d61f5


Kai Kang (1):
  mtree: add recipe

 recipes-security/mtree/mtree/mtree-getlogin.patch | 49 +++
 recipes-security/mtree/mtree_1.0.3.bb | 22 ++
 2 files changed, 71 insertions(+)
 create mode 100644 recipes-security/mtree/mtree/mtree-getlogin.patch
 create mode 100644 recipes-security/mtree/mtree_1.0.3.bb

-- 
2.10.1

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

[yocto] [PATCH] mtree: add recipe

2017-05-18 Thread kai.kang

From: Kai Kang 

Add recipe mtree port from BSD. Add a patch to handle null return
from getlogin.

Signed-off-by: Kai Kang 
---
 recipes-security/mtree/mtree/mtree-getlogin.patch | 49 +++
 recipes-security/mtree/mtree_1.0.3.bb | 22 ++
 2 files changed, 71 insertions(+)
 create mode 100644 recipes-security/mtree/mtree/mtree-getlogin.patch
 create mode 100644 recipes-security/mtree/mtree_1.0.3.bb

diff --git a/recipes-security/mtree/mtree/mtree-getlogin.patch 
b/recipes-security/mtree/mtree/mtree-getlogin.patch
new file mode 100644
index 000..35b0f8d
--- /dev/null
+++ b/recipes-security/mtree/mtree/mtree-getlogin.patch
@@ -0,0 +1,49 @@
+Upstream-Status: Pending
+
+Handle NULL return from getlogin.
+
+Signed-off-by: Kai Kang 
+---
+diff --git a/create.c b/create.c
+index e2d24d3..583af9b 100644
+--- a/create.c
 b/create.c
+@@ -77,6 +77,29 @@ static void output(int, int *, const char *, ...) 
__attribute__ ((__format__
+ static int  statd(FTS *, FTSENT *, uid_t *, gid_t *, mode_t *, u_long *);
+ static void statf(int, FTSENT *);
+ 
++char *my_getlogin()
++{
++const char *s = getlogin();
++if (s && *s)
++return s;
++
++struct passwd *p = getpwuid(geteuid());
++char *ss;
++if (p && p->pw_name) {
++if (asprintf(,"(no controlling terminal) %s",p->pw_name) < 
0) {
++perror("asprintf");
++return NULL;
++}
++} else {
++if (asprintf(,"(no controlling terminal) #%d",geteuid()) < 
0) {
++perror("asprintf");
++return NULL;
++}
++}
++
++return ss;
++}
++
+ void
+ cwalk(void)
+ {
+@@ -92,7 +115,7 @@ cwalk(void)
+ (void)gethostname(host, sizeof(host));
+ (void)printf(
+ "#\t   user: %s\n#\tmachine: %s\n",
+-getlogin(), host);
++my_getlogin(), host);
+ (void)printf(
+ "#\t   tree: %s\n#\t   date: %s",
+ fullpath, ctime());
diff --git a/recipes-security/mtree/mtree_1.0.3.bb 
b/recipes-security/mtree/mtree_1.0.3.bb
new file mode 100644
index 000..17d1cf7
--- /dev/null
+++ b/recipes-security/mtree/mtree_1.0.3.bb
@@ -0,0 +1,22 @@
+SUMMARY = "BSD directory hierarchy mapping tool"
+DESCRIPTION = "mtree compares a file hierarchy against a specification, 
creates a specification for a file hierarchy, or modifies a specification."
+
+SECTION = "utils"
+
+LICENSE = "BSD"
+LIC_FILES_CHKSUM = "file://COPYING;md5=bb19ea4eac951288efda4010c5c669a8"
+
+SRC_URI = "git://github.com/archiecobbs/mtree-port.git \
+   file://mtree-getlogin.patch \
+   "
+SRCREV = "172e1827c381ff3851cc99edb5fd89443cf260e9"
+
+S = "${WORKDIR}/git"
+
+DEPENDS = "openssl"
+
+inherit autotools
+
+do_configure_prepend() {
+touch ${S}/NEWS ${S}/AUTHORS ${S}/ChangeLog
+}
-- 
2.10.1

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

Re: [yocto] Install Torch7

2017-05-18 Thread Fabien Lahoudere

On Wed, 2017-05-17 at 08:37 +, Abayiz wrote:
> Dear all, 
> 
> I'm quite new to Yocto, I've successfully built qemu and ran helloworld 
> example on it. Now I'm
> trying to install Torch 7 (https://github.com/torch/torch7) library. What I 
> did is: 
> 
> devtool add torch https://github.com/torch/torch7.git
> devtool build torch
> 
> But the build exits with error, in the attachment I share the log file with 
> you. 
> My host machine runs Ubuntu 16.04 LTS, and Torch7 is successfully running on 
> it. The installation
> of Torch first requires to run the 'bash install-deps' command on Ubuntu. My 
> rough estimation is
> that Yocto seems like cannot build those dependencies automatically. 
> 
> Could someone give any help on it? Installing Torch7 is very important to my 
> project now, thank
> you in advance. 
> 

Do you try "devtool edit-recipe torch" to add dependencies to the recipe and 
configure "cache
variables" approprietly?

> Best, 
> Abayiz
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [infra] Intermittent outages for Yocto Project services starting soon

2017-05-18 Thread Michael Halstead

Maintenance of our ISP's connectivity at the Internet Exchange at
Portland, will cause service interruptions for some users. Most services
including git, mail, autobuilder, wiki, and website will be affected.

Planned Start: May 18, 2017 12:00AM PDT / 07:00  UTC
Expected End: May 18, 2017 6:00AM PDT / 13:00 UTC

Apologies for the short notice.

-- 
Michael Halstead
Linux Foundation / SysAdmin
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

37 matches

Mail list logo