Re: [yocto] Bluetooth

2017-12-14 Thread Dengke Du



On 2017年12月15日 13:55, Sherif Omran wrote:

when i do hciattach, i get initialization timeout.


This is a bug for initialization timeout:

    https://github.com/agherzan/meta-raspberrypi/issues/148

Sometimes it works, sometimes it would not work. Still need research on it.


could it be a branch related?


Not branch related.


I am using the morty branch
meta-yocto-bsp: morty
meta-raspberrypi: morty


On Fri, Dec 15, 2017 at 6:30 AM, Dengke Du > wrote:


You should attach the bluez stack with the raspberry firmware bcm43xx:

    hciattact -n /dev/ttyAMA0 bcm43xx 921600 noflow -

or if you use systemd:

    systemctl restart brcm43438.service

Now you can see the the device:

    rfkill list all

Enable it:

    rfkill unblock all

    hciconfig hci0 up

Checking the bluetooth:

    hciconfig -a


On 2017年12月15日 12:43, Sherif Omran wrote:

hello

i ve been strugggeling since couple of days with raspberry pi 0
board and can not figure out how to enable the chip, whether it
is enabled by default or it needs some intervention. I generated
the rpi-basic-image and tested with the hiconfigure -a but the
chip is not detected.

Any body had similar issue and got it to solve?







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


Re: [yocto] Bluetooth

2017-12-14 Thread Dengke Du

You should attach the bluez stack with the raspberry firmware bcm43xx:

    hciattact -n /dev/ttyAMA0 bcm43xx 921600 noflow -

or if you use systemd:

    systemctl restart brcm43438.service

Now you can see the the device:

    rfkill list all

Enable it:

    rfkill unblock all

    hciconfig hci0 up

Checking the bluetooth:

    hciconfig -a


On 2017年12月15日 12:43, Sherif Omran wrote:

hello

i ve been strugggeling since couple of days with raspberry pi 0 board 
and can not figure out how to enable the chip, whether it is enabled 
by default or it needs some intervention. I generated the 
rpi-basic-image and tested with the hiconfigure -a but the chip is not 
detected.


Any body had similar issue and got it to solve?




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


[yocto] Bluetooth

2017-12-14 Thread Sherif Omran
hello

i ve been strugggeling since couple of days with raspberry pi 0 board and
can not figure out how to enable the chip, whether it is enabled by default
or it needs some intervention. I generated the rpi-basic-image and tested
with the hiconfigure -a but the chip is not detected.

Any body had similar issue and got it to solve?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] Release Candidate Build for yocto-2.3.3.rc1 now available.

2017-12-14 Thread Poky Build User

A release candidate build for yocto-2.3.3.rc1 is now available at:


https://autobuilder.yocto.io/pub/releases/yocto-2.3.3.rc1


Please begin QA on this build as soon as possible.


Build hash information: 
meta-intel : 4cd63f57820ce0e4ebd598251d3a13b5a4b9b791 
meta-qt4 : 88989ae3abe98b30089e7518d3adabe990c40a10 
refkit : f24883b7d360de3eed89badce4b7fdaf7d6492c1 
meta-mingw : 4bdb99650a053f254ccd158a6d0c25c80e79f6ee 
meta-qt3 : f33b73a9563f2dfdfd0ee37b61d65d90197a456f 
meta-gplv2 : c7f97f199a6dd54d3f369f0465a6bfd2cfa739b9 
poky : 022df4653576c72752156bef8fda0e1aa46733d2 

\nThis is an automated message from\nThe Yocto Project Autobuilder\nGit: 
git://git.yoctoproject.org/yocto-autobuilder\nEmail: joshua.g.l...@intel.com 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] How to disable a linux virtual terminal...

2017-12-14 Thread Andre McCurdy
On Thu, Dec 14, 2017 at 1:51 PM, Greer, Charles (ext)
 wrote:
> Hi all,
>
> Would anyone know how to disable the virtual terminals in linux?  I am using
> Yocto, Morty version on an i.MX6 processor.

Try adding:

  USE_VT = "0"

to your machine config file.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] How to disable a linux virtual terminal...

2017-12-14 Thread Greer, Charles (ext)
Hi all,

Would anyone know how to disable the virtual terminals in linux?  I am using 
Yocto, Morty version on an i.MX6 processor.  Even though our base distribution 
is Yocto, unfortunately we have diverged from building it with recipes, so this 
is more of a straight linux question than Yocto...

To give some detail as to my problem:  It is for an embedded device that has an 
HDMI port - when I attach a terminal to the HDMI port it shows the Linux 
Penguin logo, a getty service and blanks out after 600 seconds.  I just want to 
use the hdmi port as an output with nothing displayed on the output and I want 
it to stay on all the time.

I have found that the hdmi port maps to /dev/tty1 - when I type:  echo 
"asdfasdf" > /dev/tty1 I see the characters output to the monitor.

Here are a few things I have tried to no avail - a lot of these are not needed 
if I can figure out how to disable it as a virtual terminal...


* I figured out how to disable the getty service but a cursor still 
blinks.   I don't even want a cursor to show



* I have tried to disable the display of the penguins  by disabling the 
LOGO in the kernel config parameters:
#CONFIG_LOGO=y
#CONFIG_LOGO_LINUX_MONO=y
#CONFIG_LOGO_LINUX_VGA16=y
#CONFIG_LOGO_LINUX_CLUT224=y

To no avail.  The logo still shows ::( .


* The fact that it blanks after 600 seconds is console blanking - I can 
see it set to 600 in the file:  /sys/module/kernel/parameters/consoleblank.  
When I issue the command:  echo -e '\033[9;0]'>/dev/tty1

It sets the console blanking to 0 and wakes the terminal.  Being able to wake 
the console up is limited success but I would like to disable the virtual 
terminal altogether...


* I tried commenting out these virtual terminal defines in the config 
file to no avail:
#CONFIG_VT=y
#CONFIG_VT_CONSOLE=y
#CONFIG_VT_CONSOLE_SLEEP=y
#CONFIG_HW_CONSOLE=y
#CONFIG_VT_HW_CONSOLE_BINDING=y


Everything I have read suggests that /dev/tty1 is a virtual terminal or 
console.  From what I read about the VT option, disabling the CONFIG_VT should 
do it:

VT - Virtual terminal

Say yes here to get support for terminal devices with display and keyboard 
devices. These are called "virtual" because you can run several virtual 
terminals (also called virtual consoles) on one physical terminal.

You need at least one virtual terminal device in order to make use of your 
keyboard and monitor. Therefore, only people configuring an embedded system 
would want to say no here in order to save some memory; the only way to log 
into such a system is then via a serial or network connection.

Virtual terminals are useful because, for example, one virtual terminal can 
display system messages and warnings, another one can be used for a text-mode 
user session, and a third could run an X session, all in parallel. Switching 
between virtual terminals is done with certain key combinations, usually 
Alt-function key.

If you are unsure, say yes, or else you won't be able to do much with your 
Linux system.
But for some reason it doesn't do anything!


* I found this thread;  
https://askubuntu.com/questions/357039/how-do-i-disable-virtual-consoles-tty1-6.
  But it is not much help since my distribution does not have any of the 
directories in the solutions offered in this thread.  For instance I do not 
have a /etc/events.d nor do I have a /etc/default/console-setup file nor do I 
have a /etc/init directory...   I imagine the reason for this is that my 
distribution uses systemd and the solutions are SysV based init maybe?

Disabling the logo or console blanking would not be necessary if I could just 
figure out how to disable that port as a terminal...

So does anyone have pointers or things I could try?  I am relatively new 
(returning after 10 years - I worked with DNX 10 years ago v2.6 and it seems 
everything I knew about init is fairly obsolete lol) to linux so I am sure I am 
missing a lot...
Thanks,

-  Chuck

This transmission is intended solely for the addressee and contains 
confidential information.
If you are not the intended recipient, please immediately inform the sender and 
delete the message and any attachments from your system.
Furthermore, please do not copy the message or disclose the contents to anyone 
unless agreed otherwise. To the extent permitted by law we shall in no way be 
liable for any damages, whatever their nature, arising out of transmission 
failures, viruses, external influence, delays and the like.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] CROPS status?

2017-12-14 Thread Martin Kelly

On 12/13/2017 12:44 PM, Avery, Brian wrote:

+ joshua.

I am no longer working on the YP, but Joshua is looking after CROPS. It is 
actually a family of containers, so some parts have been updated more recently.

-brian



Thanks Brian. Joshua, do you know the code status? Is the project still 
actively being worked on? Are there any related repositories I should be 
looking at?



On 12/13/17, 10:26 AM, "Martin Kelly"  wrote:

 Hi,
 
 I recently discovered the CROPS project at

 https://github.com/crops/crops. It looks like a great idea, but I see it
 hasn't had a commit since June 23, 2016. Is the project still active?
 
 Thanks,

 Martin
 


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


Re: [yocto] recipe to clean up files from rootfs

2017-12-14 Thread Chris Simmonds
Hi Sherif,

Maybe this is a little late, but as been said already, the best solution
is to remove psplash from your image altogether. You can to this quite
simply by adding to your conf/local.conf

IMAGE_FEATURES_remove = "splash"




Rationale: the dependency on the psplash program is (usually) set in the
image recipe. For example, in
meta/recipes-core/images/core-image-base.bb, you see

IMAGE_FEATURES += "splash"

The image class (meta/classes/image.bbclass) matches the list of
features in IMAGE_FEATURES with package names in FEATURE_PACKAGES_*. So,
in meta/classes/image.bbclass, you find

SPLASH ?= "psplash"
FEATURE_PACKAGES_splash = "${SPLASH}"

This causes "psplash" to be added to the image if IMAGE_FEATURES
contains the string "splash".

By using IMAGE_FEATURES_remove, you remove the string "splash" from the
list of features and so psplash will not be included in your image.

HTH,
Chris Simmonds.


On 14/12/17 08:14, Sherif Omran wrote:
> hi Andre
> thank you for your mail. I tried to remove this package but i don't know
> where it is installed from, i can not find it and got lost.
> 
> On Thu, Dec 14, 2017 at 9:11 AM, Sherif Omran  > wrote:
> 
> hi Martin,
> 
> thank you for help .. well done .. it should now work..
> 
> On Thu, Dec 14, 2017 at 8:17 AM, Martin Hundebøll
> > wrote:
> 
> Hi Sherif,
> 
> On 2017-12-14 08:06, Sherif Omran wrote:
> 
> Here is my recipe, it runs suceeds but does not delete the files
> 
> mypostprocesfunction() {
> rm -r ${IMAGE_ROOTFS}/etc/init.d/psplash.sh
> rm -r ${IMAGE_ROOTFS}/usr/bin/psplash*
> }
> 
> ROOTFS_POSTPROCESS_COMMAND += "mypostprocessfunction; "
> 
> 
> Unless you did a copy-paste error, there's a typo in the
> function name:
> mypostprocesfunction
> mypostprocessfunction
> 
> // Martin
> 
> 
> On Wed, Dec 13, 2017 at 2:03 PM, Mike Looijmans
> 
>  >> wrote:
> 
>     ${D} won't work here, grep on ROOTFS_POSTPROCESS_COMMAND
> for recipes
>     that get it right.
> 
>     And, much much much better would be to just not install
> psplash into
>     your image!
> 
>     On 13-12-17 09:10, Sherif Omran wrote:
> 
>         here is my recipe, the aim was to remove some files
> from the
>         init.d folder and tweek before creating the image
> 
>         #
>         # This file was derived from the 'Hello World!'
> example recipe
>         in the
>         # Yocto Project Development Manual.
>         #
> 
>         SUMMARY = "This recipe removes any missing files
> from the
>         filesystem before finalinzing it"
>         SECTION = "base"
>         LICENSE = "MIT"
>         LIC_FILES_CHKSUM =
>        
> 
> "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
> 
>         #SRC_URI = "file://*"
> 
>         S = "${WORKDIR}"
>         BB_STRICT_CHECKSUM ="0"
>         ALLOW_EMPTY_${PN}="1"
> 
> 
>         #IMAGE_INSTALL = "packagegroup-core-boot
>         packagegroup-base-extended ${CORE_IMAGE_EXTRA_INSTALL}"
>         #IMAGE_INSTALL = "${CORE_IMAGE}"
> 
>         #inherit core-image
> 
>         my_postprocess_function() {
>            rm -r ${D}${bindir}/init.d/psplash.sh
>         }
> 
>         ROOTFS_POSTPROCESS_COMMAND +=
> "my_postprocess_function; "
> 
>         On Wed, Dec 13, 2017 at 7:22 AM, Mike Looijmans
>          
>  >
>          
>           
>              Well, start by sharing yours first.
> 
>              Be careful when naming your shell routine,
> sometimes OE
>         considers parts
>              behind the underscore as overrides and then it
> cannot find it.
> 
> 
>              On 13-12-17 07:14, Sherif Omran wrote:
> 
>                  hi Mike,
>                  i 

Re: [yocto] [PATCH 08/12] upgradehelper.py: clean repo only once when recipes are specified

2017-12-14 Thread Alexander Kanavin

On 12/14/2017 04:13 AM, Robert Yang wrote:

How about simply issuing 'git revert' after a build has failed? 
That's easier to implement than rearranging the order of commits, 
and the commit message can include a link to the build failure logs.


Sounds reasonable to me, I will update the patch.


Wait until I publish my devtool port, then if you could rebase on 
that, that'd be great!


Got it, thanks.


I just sent the patches to yocto@ ML and published them on github - 
please do try them out, and rebase your patchset on top (some of it may 
no longer be relevant).



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


[yocto] [auh][PATCH 20/20] upgradehelper.py: revert commits that failed to build

2017-12-14 Thread Alexander Kanavin
From: Alexander Kanavin 

This helps avoid 'cascading build failures' where one failed update
holds up everything else.

Signed-off-by: Alexander Kanavin 
---
 modules/utils/git.py | 3 +++
 upgradehelper.py | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/modules/utils/git.py b/modules/utils/git.py
index 0e812b9..749d24d 100644
--- a/modules/utils/git.py
+++ b/modules/utils/git.py
@@ -61,6 +61,9 @@ class Git(object):
 else:
 return self._cmd("commit -a --author=\"" + author + "\" -m \"" + 
commit_message + "\"")
 
+def revert(self, commit):
+return self._cmd("revert --no-edit " + commit)
+
 def create_patch(self, out_dir):
 return self._cmd("format-patch -M10 -1 -o " + out_dir)
 
diff --git a/upgradehelper.py b/upgradehelper.py
index 58fa0a6..71ee0b0 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -414,6 +414,9 @@ class Updater(object):
 else:
 I(" %s: Save patch in directory: %s." %
 (pkg_ctx['PN'], pkg_ctx['workdir']))
+if pkg_ctx['error'] is not None:
+I("Due to build errors, the commit will also be reverted to 
avoid cascading upgrade failures.")
+self.git.revert("HEAD")
 except Error as e:
 msg = ''
 
-- 
2.15.0

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


[yocto] [auh][PATCH 19/20] upgradehelper.py: when recovering from upgrade error, do not refer to a dict entry that may not exist

2017-12-14 Thread Alexander Kanavin
From: Alexander Kanavin 

Signed-off-by: Alexander Kanavin 
---
 upgradehelper.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/upgradehelper.py b/upgradehelper.py
index 3c41012..58fa0a6 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -510,7 +510,7 @@ class Updater(object):
 
 E(" %s: %s" % (pkg_ctx['PN'], e.message))
 
-if os.listdir(pkg_ctx['workdir']):
+if 'workdir' in pkg_ctx and os.listdir(pkg_ctx['workdir']):
 E(" %s: Upgrade FAILED! Logs and/or file diffs are 
available in %s"
 % (pkg_ctx['PN'], pkg_ctx['workdir']))
 
-- 
2.15.0

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


[yocto] [auh][PATCH 18/20] upgradehelper.py: when attempting to commit changes do not discard previous errors

2017-12-14 Thread Alexander Kanavin
From: Alexander Kanavin 

Signed-off-by: Alexander Kanavin 
---
 upgradehelper.py | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/upgradehelper.py b/upgradehelper.py
index d1f441c..3c41012 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -397,7 +397,6 @@ class Updater(object):
 f.write("\n%s\n" % msg_body)
 
 def commit_changes(self, pkg_ctx):
-fail = False
 try:
 pkg_ctx['patch_file'] = None
 
@@ -411,8 +410,7 @@ class Updater(object):
 if not pkg_ctx['patch_file']:
 msg = "Patch file not generated."
 E(" %s: %s\n %s" % (pkg_ctx['PN'], msg, stdout))
-pkg_ctx['error'] = Error(msg, stdout)
-fail = True
+raise Error(msg, stdout)
 else:
 I(" %s: Save patch in directory: %s." %
 (pkg_ctx['PN'], pkg_ctx['workdir']))
@@ -425,12 +423,7 @@ class Updater(object):
 I(" %s: %s" % (pkg_ctx['PN'], msg))
 
 I(" %s: %s" % (pkg_ctx['PN'], e.stdout))
-
-pkg_ctx['error'] = Error(msg, e.stdout)
-fail = True
-
-if fail:
-raise pkg_ctx['error']
+raise e
 
 def send_status_mail(self, statistics_summary):
 if "status_recipients" not in settings:
-- 
2.15.0

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


[yocto] [auh][PATCH 15/20] upgradehelper.py: fixups to the email message template

2017-12-14 Thread Alexander Kanavin
From: Alexander Kanavin 

Signed-off-by: Alexander Kanavin 
---
 upgradehelper.py | 43 +++
 1 file changed, 27 insertions(+), 16 deletions(-)

diff --git a/upgradehelper.py b/upgradehelper.py
index d62c9b2..d3cc2c4 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -294,19 +294,20 @@ class Updater(object):
 "to upgrade the recipe to *%s* has %s.\n\n"
 
 license_change_info = \
-"*LICENSE CHANGED* please review the %s file and update the 
LICENSE\n" \
-"variable in the recipe if is needed.\n\n"
+"*LICENSE CHANGED* please review the %s file, update the 
LICENSE\n" \
+"variable in the recipe and summarize the changes in the commit 
message.\n\n"
 
 next_steps_info = \
-"The recipe has been successfully compiled for machines %s.\n\n" \
 "Next steps:\n" \
 "- apply the patch: git am %s\n" \
-"- check that required upstream patches have not been 
commented from the recipe,\n" \
-"  if upstream patches were commented the reason is specified 
in the commit message.\n" \
+"- check the changes to upstream patches and summarize them in 
the commit message,\n" \
 "- compile an image that contains the package\n" \
 "- perform some basic sanity tests\n" \
 "- amend the patch and sign it off: git commit -s 
--reset-author --amend\n" \
-"- send it to the list\n\n" \
+"- send it to the appropriate mailing list\n\n" \
+"Alternatively, if you believe the recipe should not be upgraded 
at this time,\n" \
+"you can fill RECIPE_NO_UPDATE_REASON in respective recipe file so 
that\n" \
+"automatic upgrades would no longer be attempted.\n\n"
 
 testimage_integration_error = \
 "The recipe *FAILED* in testimage integration. Attached is the log 
file.\n\n"
@@ -320,7 +321,7 @@ class Updater(object):
 "the next machines %s. Attached is the log file.\n\n" \
 
 mail_footer = \
-"Attached are the patch, license diff (if change) and bitbake 
log.\n" \
+"Please review the attached files for further information and 
build/update failures.\n" \
 "Any problem please file a bug at 
https://bugzilla.yoctoproject.org/enter_bug.cgi?product=Automated%20Update%20Handler\n\n;
 \
 "Regards,\nThe Upgrade Helper"
 
@@ -333,20 +334,30 @@ class Updater(object):
 if "status_recipients" in settings:
 cc_addr = settings["status_recipients"].split()
 
-subject = "[AUH] " + pkg_ctx['PN'] + ": upgrading to " + pkg_ctx['NPV']
+newversion = pkg_ctx['NPV'] if not 
pkg_ctx['NPV'].endswith("new-commits-available") else pkg_ctx['NSRCREV']
+subject = "[AUH] " + pkg_ctx['PN'] + ": upgrading to " + newversion
 if not pkg_ctx['error']:
 subject += " SUCCEEDED"
 else:
 subject += " FAILED"
-msg_body = mail_header % (pkg_ctx['PN'], pkg_ctx['NPV'],
+msg_body = mail_header % (pkg_ctx['PN'], newversion,
 self._get_status_msg(pkg_ctx['error']))
-if 'recipe' in pkg_ctx:
-license_diff_fn = pkg_ctx['recipe'].get_license_diff_file_name()
-if license_diff_fn:
-msg_body += license_change_info % license_diff_fn
-if not pkg_ctx['error']:
-msg_body += next_steps_info % (', '.join(self.opts['machines']),
-os.path.basename(pkg_ctx['patch_file']))
+
+if pkg_ctx['error'] is not None:
+msg_body += """Detailed error information:
+
+%s
+%s
+%s
+
+""" %(pkg_ctx['error'].message if pkg_ctx['error'].message else "", 
pkg_ctx['error'].stdout if pkg_ctx['error'].stdout else "" , 
pkg_ctx['error'].stderr if pkg_ctx['error'].stderr else "")
+
+if 'license_diff_fn' in pkg_ctx:
+license_diff_fn = pkg_ctx['license_diff_fn']
+msg_body += license_change_info % license_diff_fn
+
+if 'patch_file' in pkg_ctx and pkg_ctx['patch_file'] != None:
+msg_body += next_steps_info % 
(os.path.basename(pkg_ctx['patch_file']))
 
 if self.opts['testimage']:
 if 'integration_error' in pkg_ctx:
-- 
2.15.0

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


[yocto] [auh][PATCH 10/20] modules/recipe: remove

2017-12-14 Thread Alexander Kanavin
From: Alexander Kanavin 

The hand-crafted recipe updating/rewriting has been replaced by calling devtool.

Signed-off-by: Alexander Kanavin 
---
 modules/recipe/__init__.py |   0
 modules/recipe/base.py | 724 -
 modules/recipe/git.py  |  98 --
 modules/recipe/svn.py  |  28 --
 4 files changed, 850 deletions(-)
 delete mode 100644 modules/recipe/__init__.py
 delete mode 100644 modules/recipe/base.py
 delete mode 100644 modules/recipe/git.py
 delete mode 100644 modules/recipe/svn.py

diff --git a/modules/recipe/__init__.py b/modules/recipe/__init__.py
deleted file mode 100644
index e69de29..000
diff --git a/modules/recipe/base.py b/modules/recipe/base.py
deleted file mode 100644
index 3798577..000
--- a/modules/recipe/base.py
+++ /dev/null
@@ -1,724 +0,0 @@
-#!/usr/bin/env python
-# vim: set ts=4 sw=4 et:
-#
-# Copyright (c) 2013 - 2014 Intel Corporation
-#
-# This program 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.
-#
-# This program 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 this program; if not, write to the Free Software
-# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, 
USA.
-#
-# AUTHORS
-# Laurentiu Palcu   
-# Marius Avram  
-#
-
-import os
-import re
-import sys
-import logging as log
-from logging import debug as D
-from logging import info as I
-from logging import warning as W
-
-from errors import *
-from utils.bitbake import *
-
-def is_recipe_or_include_file(env, full_path_f, f):
-is_file = os.path.isfile(full_path_f)
-
-is_recipe = f.find(env['PN']) == 0 and \
-f.find(env['PKGV']) != -1 and \
-f.find(".bb") != -1
-
-is_include = f.find(env['PN']) == 0 and \
- f.find(".inc") != -1
-
-return is_file and (is_recipe or is_include)
-
-def modify_recipe_files(func):
-def modify(env, recipe_dir, *args, **kwargs):
-for f in os.listdir(recipe_dir):
-full_path_f = os.path.join(recipe_dir, f)
-if is_recipe_or_include_file(env, full_path_f, f):
-with open(full_path_f + ".tmp", "w+") as temp_recipe:
-with open(full_path_f) as recipe:
-for line in recipe:
-func(line, temp_recipe, *args, **kwargs)
-os.rename(full_path_f + ".tmp", full_path_f)
-return modify
-
-def read_recipe_files(func):
-def read(env, recipe_dir):
-for f in os.listdir(recipe_dir):
-full_path_f = os.path.join(recipe_dir, f)
-if is_recipe_or_include_file(env, full_path_f, f):
-with open(full_path_f) as recipe:
-for line in recipe:
-func(line)
-return read
-
-class Recipe(object):
-def __init__(self, env, new_ver, interactive, workdir, recipe_dir, 
bitbake, git):
-self.env = env
-self.new_ver = new_ver
-self.interactive = interactive
-self.workdir = workdir
-self.recipe_dir = recipe_dir
-self.bb = bitbake
-self.bb.set_log_dir(workdir)
-self.git = git
-
-self.retried_recipes = set()
-self.license_diff_file = None
-
-self.recipes_renamed = False
-self.checksums_changed = False
-
-self.removed_patches = False
-
-self.suffixes = [
-"tar.gz", "tgz", "zip", "tar.bz2", "tar.xz", "tar.lz4", "bz2",
-"lz4", "orig.tar.gz", "src.tar.gz", "src.rpm", "src.tgz",
-"svnr\d+.tar.bz2", "stable.tar.gz", "src.rpm"]
-self.old_env = None
-
-self.commit_msg = self.env['PN'] + ": upgrade to " + self.new_ver + 
"\n\n"
-self.comment_patches_msg = "\n\nCommented the following patch(es):\n"
-
-self._inherits = None
-
-super(Recipe, self).__init__()
-
-def get_inherits(self):
-@read_recipe_files
-def _get_inherits(line):
-m = re.search("^inherit (.*)$", line)
-if m:
-tmp = m.group(1).split()
-self._inherits.extend(tmp)
-
-if not self._inherits:
-self._inherits = []
-_get_inherits(self.env, self.recipe_dir)
-
-return self._inherits
-
-def update_env(self, env):
-self.env = env
-
-def _rename_files_dir(self, old_ver, new_ver):
-# The files directory is renamed only if the previous
-# 

[yocto] [auh][PATCH 14/20] testimage.py: add extra logging for the testimage logs retrieval

2017-12-14 Thread Alexander Kanavin
From: Alexander Kanavin 

This helped with diagnozing issues described in
https://bugzilla.yoctoproject.org/show_bug.cgi?id=12396

Signed-off-by: Alexander Kanavin 
---
 modules/testimage.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/modules/testimage.py b/modules/testimage.py
index c3352e5..6c4ed2b 100644
--- a/modules/testimage.py
+++ b/modules/testimage.py
@@ -98,8 +98,10 @@ class TestImage():
 if name in files:
 result.append(os.path.join(root, name))
 
+D("Found logs named %s for machine %s: %s" %(name, machine, result))
 for ptest_log in result:
 if machine in ptest_log:
+D("Picked log: %s" %(ptest_log))
 return ptest_log
 
 def _get_failed_recipe(self, log):
-- 
2.15.0

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


[yocto] [auh][PATCH 13/20] testimage.py: do not call into removed code

2017-12-14 Thread Alexander Kanavin
From: Alexander Kanavin 

This was using the removed recipe parsing code to determine if
a package supports ptest; it should be replaced with using bitbake API
but for now we can simply add all update packages to the list.

Signed-off-by: Alexander Kanavin 
---
 modules/testimage.py | 12 ++--
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/modules/testimage.py b/modules/testimage.py
index 23d38d4..c3352e5 100644
--- a/modules/testimage.py
+++ b/modules/testimage.py
@@ -53,15 +53,6 @@ class TestImage():
 os.environ['BB_ENV_EXTRAWHITE'] = os.environ['BB_ENV_EXTRAWHITE'] + \
 " TEST_SUITES CORE_IMAGE_EXTRA_INSTALL"
 
-def _get_ptest_pkgs(self, pkgs_ctx):
-pkgs = []
-
-for c in pkgs_ctx:
-if "ptest" in c['recipe'].get_inherits():
-pkgs.append(c)
-
-return pkgs
-
 def _get_pkgs_to_install(self, pkgs, ptest=False):
 pkgs_out = []
 
@@ -149,7 +140,8 @@ class TestImage():
 
 def ptest(self, pkgs_ctx, machine):
 image = 'core-image-minimal'
-ptest_pkgs = self._get_ptest_pkgs(pkgs_ctx)
+# should use bitbake API here to trim down the list to only the 
recipes that inherit ptest
+ptest_pkgs = pkgs_ctx
 
 os.environ['CORE_IMAGE_EXTRA_INSTALL'] = \
 self._get_pkgs_to_install(ptest_pkgs, ptest=True)
-- 
2.15.0

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


[yocto] [auh][PATCH 11/20] upgradehelper.py: remove the package ordering code

2017-12-14 Thread Alexander Kanavin
From: Alexander Kanavin 

It was broken and commented out, and not really necessary.

Signed-off-by: Alexander Kanavin 
---
 upgradehelper.py | 80 
 1 file changed, 80 deletions(-)

diff --git a/upgradehelper.py b/upgradehelper.py
index 9fa79b4..d62c9b2 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -439,87 +439,7 @@ class Updater(object):
 else:
 W("No recipes attempted, not sending status mail!")
 
-def _order_pkgs_to_upgrade(self, pkgs_to_upgrade):
-def _get_pn_dep_dic(pn_list, dependency_file): 
-import re
-
-pn_dep_dic = {}
-
-with open(dependency_file) as dep:
-data = dep.read()
-dep.close()
-
-for line in data.split('\n'):
-m = re.search('^"(.*)" -> "(.*)"$', line)
-if not m:
-continue
-
-pn = m.group(1)
-pn_dep = m.group(2)
-if pn == pn_dep:
-continue
-
-if pn in pn_list:
-if pn_dep in pn_list:
-if pn in pn_dep_dic.keys():
-pn_dep_dic[pn].append(pn_dep)
-else:
-pn_dep_dic[pn] = [pn_dep]
-elif not pn in pn_dep_dic.keys():
-pn_dep_dic[pn] = []
-
-return pn_dep_dic
-
-def _dep_resolve(graph, node, resolved, seen):
-seen.append(node)
-
-for edge in graph[node]:
-if edge not in resolved:
-if edge in seen:
-raise RuntimeError("Packages %s and %s have " \
-"a circular dependency." \
-% (node, edge))
-_dep_resolve(graph, edge, resolved, seen)
-
-resolved.append(node)
-
-
-pn_list = []
-for pn, new_ver, maintainer in pkgs_to_upgrade:
-pn_list.append(pn)
-
-try:
-   self.bb.dependency_graph(' '.join(pn_list))
-except Error as e:
-multiple_providers = False
-for l in e.stdout.split('\n'):
-if l.find("ERROR: Multiple .bb files are due to be built which 
each provide") == 0:
-multiple_providers = True
-if not multiple_providers:
-raise e
-
-dependency_file = os.path.join(get_build_dir(), "pn-depends.dot")
-
-pkgs_to_upgrade_ordered = []
-pn_list_ordered = []
-
-pn_dep_dic = _get_pn_dep_dic(pn_list, dependency_file)
-if pn_dep_dic:
-root = "__root_node__"
-pn_dep_dic[root] = pn_dep_dic.keys()
-_dep_resolve(pn_dep_dic, root, pn_list_ordered, [])
-pn_list_ordered.remove(root)
-
-for pn_ordered in pn_list_ordered:
-for pn, new_ver, maintainer in pkgs_to_upgrade:
-if pn == pn_ordered: 
-pkgs_to_upgrade_ordered.append([pn, new_ver, maintainer])
-
-return pkgs_to_upgrade_ordered
-
 def run(self, package_list=None):
-#pkgs_to_upgrade = self._order_pkgs_to_upgrade(
-#self._get_packages_to_upgrade(package_list))
 pkgs_to_upgrade = self._get_packages_to_upgrade(package_list)
 total_pkgs = len(pkgs_to_upgrade)
 
-- 
2.15.0

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


[yocto] [auh][PATCH 12/20] utils/git.py: print current dir when git fails

2017-12-14 Thread Alexander Kanavin
From: Alexander Kanavin 

Signed-off-by: Alexander Kanavin 
---
 modules/utils/git.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/modules/utils/git.py b/modules/utils/git.py
index d1fe41b..a6f5422 100644
--- a/modules/utils/git.py
+++ b/modules/utils/git.py
@@ -40,7 +40,7 @@ class Git(object):
 try:
 stdout, stderr = bb.process.run(cmd)
 except bb.process.ExecutionError as e:
-D("%s returned:\n%s" % (cmd, e.__str__()))
+D("%s executed from %s returned:\n%s" % (cmd, self.repo_dir, 
e.__str__()))
 raise Error("The following git command failed: " + operation,
 e.stdout, e.stderr)
 
-- 
2.15.0

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


[yocto] [auh][PATCH 09/20] Replace references to Aníbal Limón as the maintainer.

2017-12-14 Thread Alexander Kanavin
From: Alexander Kanavin 

Signed-off-by: Alexander Kanavin 
---
 README   | 2 +-
 upgradehelper.py | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/README b/README
index e6b0dc2..60dbef9 100644
--- a/README
+++ b/README
@@ -163,7 +163,7 @@ The latest version of the code can always be found here:
 
 Contributions are welcome. Please send patches / pull requests to
 yocto@yoctoproject.org with '[auh]' in the subject also CC the
-current maintainer: Aníbal Limón .
+current maintainer: Alex Kanavin .
 
 License
 ---
diff --git a/upgradehelper.py b/upgradehelper.py
index 5149993..9fa79b4 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -321,7 +321,7 @@ class Updater(object):
 
 mail_footer = \
 "Attached are the patch, license diff (if change) and bitbake 
log.\n" \
-"Any problem please contact Anibal Limon 
.\n\n" \
+"Any problem please file a bug at 
https://bugzilla.yoctoproject.org/enter_bug.cgi?product=Automated%20Update%20Handler\n\n;
 \
 "Regards,\nThe Upgrade Helper"
 
 if pkg_ctx['MAINTAINER'] in maintainer_override:
-- 
2.15.0

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


[yocto] [auh][PATCH 08/20] testimage.py: do not manipulate branches

2017-12-14 Thread Alexander Kanavin
From: Alexander Kanavin 

AUH simply creates a series of commits now, so we can create and
run testimage directly on the branch we're on.

Signed-off-by: Alexander Kanavin 
---
 modules/testimage.py | 32 
 1 file changed, 32 deletions(-)

diff --git a/modules/testimage.py b/modules/testimage.py
index da5c433..23d38d4 100644
--- a/modules/testimage.py
+++ b/modules/testimage.py
@@ -75,33 +75,6 @@ class TestImage():
 
 return ' '.join(pkgs_out)
 
-def prepare_branch(self, pkgs_ctx):
-ok = False
-
-try:
-self.git.reset_hard()
-self.git.checkout_branch("master")
-
-try:
-self.git.delete_branch("testimage")
-except Error:
-pass
-
-self.git.create_branch("testimage")
-for c in pkgs_ctx:
-patch_file = os.path.join(c['workdir'], c['patch_file'])
-try:
-self.git.apply_patch(patch_file)
-except Exception as e:
-c['integration_error'] = e
-self.git.abort_patch()
-
-ok = True
-except Exception as e:
-self._log_error(" testimage: Failed to prepare branch.")
-
-return ok
- 
 def _parse_ptest_log(self, log_file):
 ptest_results = {}
 
@@ -284,8 +257,6 @@ class TestImage():
 
 self.pkgs_ctx.remove(pkg_ctx)
 
-if not self.prepare_branch(self.pkgs_ctx):
-handled = False
 else:
 handled = False
 
@@ -296,9 +267,6 @@ class TestImage():
 I(" Testimage was enabled but any upgrade was successful.")
 return
 
-if not self.prepare_branch(self.pkgs_ctx):
-   return
-
 I(" Images will test for %s." % ', '.join(self.opts['machines']))
 for machine in self.opts['machines']:
 I("  Testing images for %s ..." % machine)
-- 
2.15.0

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


[yocto] [auh][PATCH 07/20] buildhistory.py: replace cleanall with cleansstate

2017-12-14 Thread Alexander Kanavin
From: Alexander Kanavin 

It should not be really necessary, and wastes time
as the upstream source needs to be re-fetched.

Signed-off-by: Alexander Kanavin 
---
 modules/buildhistory.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/modules/buildhistory.py b/modules/buildhistory.py
index 9085233..e78da05 100644
--- a/modules/buildhistory.py
+++ b/modules/buildhistory.py
@@ -49,7 +49,7 @@ class BuildHistory(object):
 os.environ["BUILDHISTORY_DIR"] = self.buildhistory_dir
 
 def init(self, machines):
-self.bb.cleanall(self.pn)
+self.bb.cleansstate(self.pn)
 for machine in machines:
 self.bb.complete(self.pn, machine)
 self.revs.append(self.git.last_commit("master"))
-- 
2.15.0

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


[yocto] [auh][PATCH 06/20] Add devtool support for upgrading recipes

2017-12-14 Thread Alexander Kanavin
From: Alexander Kanavin 

devtool has a much better support for rebasing patches,
can be used interactively when things go wrong, and we
also need to avoid having two codebases for updating
recipes that broadly do the same thing.

Signed-off-by: Alexander Kanavin 
---
 modules/errors.py|   7 +-
 modules/steps.py | 191 ++-
 modules/utils/devtool.py |  41 ++
 upgradehelper.py |  30 
 4 files changed, 151 insertions(+), 118 deletions(-)
 create mode 100644 modules/utils/devtool.py

diff --git a/modules/errors.py b/modules/errors.py
index ba87180..ad56215 100644
--- a/modules/errors.py
+++ b/modules/errors.py
@@ -33,8 +33,11 @@ class Error(Exception):
 
 class MaintainerError(Error):
 """ Class for group error that can be sent to Maintainer's """
-def __init__(self, message=None, stdout=None, stderr=None):
-super(MaintainerError, self).__init__(message, stdout, stderr)
+
+class DevtoolError(Error):
+""" Class for devtool errors """
+def __str__(self):
+return "Failed (devtool error)"
 
 class FetchError(Error):
 def __init__(self):
diff --git a/modules/steps.py b/modules/steps.py
index 0c527a4..63f43c8 100644
--- a/modules/steps.py
+++ b/modules/steps.py
@@ -21,6 +21,8 @@
 import os
 import sys
 import subprocess
+import shutil
+import re
 
 from logging import debug as D
 from logging import info as I
@@ -31,40 +33,7 @@ from logging import critical as C
 from errors import *
 from buildhistory import BuildHistory
 
-from recipe.base import Recipe
-from recipe.git import GitRecipe
-from recipe.svn import SvnRecipe
-
-def clean_repo(bb, git, opts, pkg_ctx):
-git.checkout_branch("master")
-
-try:
-git.delete_branch("remove_patches")
-except:
-pass
-try:
-git.delete_branch("upgrades")
-except:
-pass
-
-git.reset_hard()
-git.create_branch("upgrades")
-
-def load_env(bb, git, opts, pkg_ctx):
-stdout = git.status()
-if stdout != "":
-if opts['interactive']:
-W(" %s: git repository has uncommited work which will be dropped!" 
\
-" Proceed? (y/N)" % pkg_ctx['PN'])
-answer = sys.stdin.readline().strip().upper()
-if answer == '' or answer != 'Y':
-I(" %s: User abort!" % pkg_ctx['PN'])
-exit(1)
-
-I(" %s: Dropping uncommited work!" % pkg_ctx['PN'])
-git.reset_hard()
-git.clean_untracked()
-
+def load_env(devtool, bb, git, opts, pkg_ctx):
 pkg_ctx['env'] = bb.env(pkg_ctx['PN'])
 pkg_ctx['workdir'] = os.path.join(pkg_ctx['base_dir'], pkg_ctx['PN'])
 os.mkdir(pkg_ctx['workdir'])
@@ -73,97 +42,117 @@ def load_env(bb, git, opts, pkg_ctx):
 if pkg_ctx['env']['PV'] == pkg_ctx['NPV']:
 raise UpgradeNotNeededError
 
-def detect_recipe_type(bb, git, opts, pkg_ctx):
-if pkg_ctx['env']['SRC_URI'].find("ftp://;) != -1 or  \
-pkg_ctx['env']['SRC_URI'].find("http://;) != -1 or \
-pkg_ctx['env']['SRC_URI'].find("https://;) != -1:
-recipe = Recipe
-elif pkg_ctx['env']['SRC_URI'].find("git://") != -1:
-recipe = GitRecipe
-else:
-raise UnsupportedProtocolError
-
-pkg_ctx['recipe'] = recipe(pkg_ctx['env'], pkg_ctx['NPV'],
-opts['interactive'], pkg_ctx['workdir'],
-pkg_ctx['recipe_dir'], bb, git)
-
-def buildhistory_init(bb, git, opts, pkg_ctx):
+def buildhistory_init(devtool, bb, git, opts, pkg_ctx):
 if not opts['buildhistory']:
 return
 
 pkg_ctx['buildhistory'] = BuildHistory(bb, pkg_ctx['PN'],
 pkg_ctx['workdir'])
 I(" %s: Initial buildhistory for %s ..." % (pkg_ctx['PN'],
-opts['machines']))
-pkg_ctx['buildhistory'].init(opts['machines'])
-
-def unpack_original(bb, git, opts, pkg_ctx):
-pkg_ctx['recipe'].unpack()
-
-def pack_original_workdir(bb, git, opts, pkg_ctx):
-recipe_workdir = os.path.dirname(pkg_ctx['env']['S'])
-pkg_ctx['recipe_workdir_tarball'] = os.path.join(pkg_ctx['workdir'],
-'original_workdir.tar.gz')
-
-try:
-subprocess.call(["tar", "-chzf", pkg_ctx['recipe_workdir_tarball'],
- recipe_workdir], stdout=subprocess.PIPE,
- stderr=subprocess.PIPE)
-except:
-W(" %s, Can't compress original workdir, if license diff" \
-  " is needed will show full file." % pkg_ctx['PN'])
-
-def rename(bb, git, opts, pkg_ctx):
-pkg_ctx['recipe'].rename()
-
-pkg_ctx['env'] = bb.env(pkg_ctx['PN'])
-
-pkg_ctx['recipe'].update_env(pkg_ctx['env'])
-
-def cleanall(bb, git, opts, pkg_ctx):
-pkg_ctx['recipe'].cleanall()
-
-def fetch(bb, git, opts, pkg_ctx):
-pkg_ctx['recipe'].fetch()
+opts['machines'][:1]))
+pkg_ctx['buildhistory'].init(opts['machines'][:1])
+
+def _extract_license_diff(devtool_output):
+   

[yocto] [auh][PATCH 05/20] upgradehelper.py: add the old recipe version in pkg_ctx

2017-12-14 Thread Alexander Kanavin
From: Alexander Kanavin 

So that it can be later used in the commit message.

Signed-off-by: Alexander Kanavin 
---
 upgradehelper.py | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/upgradehelper.py b/upgradehelper.py
index c11993a..9a59941 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -526,12 +526,13 @@ class Updater(object):
 pkgs_ctx = {}
 
 I(" ### The list of recipes to be upgraded #")
-for p, v, m, r in pkgs_to_upgrade:
-I(" %s, %s, %s, %s" % (p, v, m, r))
+for p, ov, nv, m, r in pkgs_to_upgrade:
+I(" %s, %s, %s, %s, %s" % (p, ov, nv, m, r))
 
 pkgs_ctx[p] = {}
 pkgs_ctx[p]['PN'] = p
-pkgs_ctx[p]['NPV'] = v
+pkgs_ctx[p]['PV'] = ov
+pkgs_ctx[p]['NPV'] = nv
 pkgs_ctx[p]['MAINTAINER'] = m
 pkgs_ctx[p]['NSRCREV'] = r
 
@@ -556,7 +557,7 @@ class Updater(object):
 succeeded_pkgs_ctx = []
 failed_pkgs_ctx = []
 attempted_pkgs = 0
-for pn, _, _, _ in pkgs_to_upgrade:
+for pn, _, _, _, _ in pkgs_to_upgrade:
 pkg_ctx = pkgs_ctx[pn]
 pkg_ctx['error'] = None
 
@@ -744,7 +745,7 @@ class UniverseUpdater(Updater):
 no_upgrade_reason = row[15]
 
 if status == 'UPDATE' and not no_upgrade_reason:
-pkgs_list.append((pn, next_ver, maintainer, revision))
+pkgs_list.append((pn, cur_ver, next_ver, maintainer, 
revision))
 else:
 if no_upgrade_reason:
 D(" Skip package %s (status = %s, current version = 
%s," \
-- 
2.15.0

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


[yocto] [auh][PATCH 04/20] upgradehelper.py: support updates to a new vcs revision.

2017-12-14 Thread Alexander Kanavin
From: Alexander Kanavin 

Devtool has support for this, and it's useful when the upstream
never issues new versions; in this situation we can simply
attempt to update to the latest revision.

Signed-off-by: Alexander Kanavin 
---
 upgradehelper.py | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/upgradehelper.py b/upgradehelper.py
index 5fb65cd..c11993a 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -526,13 +526,14 @@ class Updater(object):
 pkgs_ctx = {}
 
 I(" ### The list of recipes to be upgraded #")
-for p, v, m in pkgs_to_upgrade:
-I(" %s, %s, %s" % (p, v, m))
+for p, v, m, r in pkgs_to_upgrade:
+I(" %s, %s, %s, %s" % (p, v, m, r))
 
 pkgs_ctx[p] = {}
 pkgs_ctx[p]['PN'] = p
 pkgs_ctx[p]['NPV'] = v
 pkgs_ctx[p]['MAINTAINER'] = m
+pkgs_ctx[p]['NSRCREV'] = r
 
 pkgs_ctx[p]['base_dir'] = self.uh_recipes_all_dir
 I(" ")
@@ -555,7 +556,7 @@ class Updater(object):
 succeeded_pkgs_ctx = []
 failed_pkgs_ctx = []
 attempted_pkgs = 0
-for pn, _, _ in pkgs_to_upgrade:
+for pn, _, _, _ in pkgs_to_upgrade:
 pkg_ctx = pkgs_ctx[pn]
 pkg_ctx['error'] = None
 
@@ -738,11 +739,12 @@ class UniverseUpdater(Updater):
 cur_ver = row[1]
 next_ver = row[2]
 status = row[11]
+revision = row[12]
 maintainer = row[14]
 no_upgrade_reason = row[15]
 
 if status == 'UPDATE' and not no_upgrade_reason:
-pkgs_list.append((pn, next_ver, maintainer))
+pkgs_list.append((pn, next_ver, maintainer, revision))
 else:
 if no_upgrade_reason:
 D(" Skip package %s (status = %s, current version = 
%s," \
-- 
2.15.0

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


[yocto] [auh][PATCH 03/20] upgradehelper.py: do not manipulate git branches.

2017-12-14 Thread Alexander Kanavin
From: Alexander Kanavin 

Let's just write the commits into the current branch, and leave
branch management to some other tool.

Signed-off-by: Alexander Kanavin 
---
 upgradehelper.py | 25 -
 1 file changed, 25 deletions(-)

diff --git a/upgradehelper.py b/upgradehelper.py
index 651345b..5fb65cd 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -695,30 +695,6 @@ class UniverseUpdater(Updater):
 
 return recipes
 
-def _update_master(self):
-if self.opts['layer_mode'] == 'yes':
-I(" Sync poky master ...")
-self.poky_git.reset_hard()
-self.poky_git.clean_untracked()
-self.poky_git.checkout_branch("master")
-self.poky_git.pull()
-
-I(" Drop all uncommited changes (including untracked) ...")
-self.git.reset_hard()
-self.git.clean_untracked()
-
-self.git.checkout_branch("master")
-try:
-self.git.delete_branch("upgrades")
-except Error:
-pass
-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")
-
 def _prepare(self):
 if settings.get("clean_sstate", "no") == "yes" and \
 os.path.exists(os.path.join(get_build_dir(), "sstate-cache")):
@@ -857,7 +833,6 @@ class UniverseUpdater(Updater):
 self._get_status_msg(pkg_ctx['error']))
 
 def run(self):
-self._update_master()
 self._prepare()
 super(UniverseUpdater, self).run()
 
-- 
2.15.0

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


[yocto] [auh][PATCH 02/20] upgradehelper.py: always run checkpkg

2017-12-14 Thread Alexander Kanavin
From: Alexander Kanavin 

There was code to skip upstream version check if it was performed
recently, which was actually broken as it didn't verify that
checkpkg.csv already contains the package we want to update.
Let's just drop the whole logic and run checkpkg always.

Signed-off-by: Alexander Kanavin 
---
 upgradehelper.py | 33 ++---
 1 file changed, 2 insertions(+), 31 deletions(-)

diff --git a/upgradehelper.py b/upgradehelper.py
index 1356aef..651345b 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -829,43 +829,14 @@ class UniverseUpdater(Updater):
 return True
 
 def _get_packages_to_upgrade(self, packages=None):
-last_date_checked = None
-last_master_commit = None
-last_checkpkg_file = None
-current_date = date.isoformat(date.today())
-try:
-stdout = self.git.last_commit("master")
-cur_master_commit = stdout
-except Error:
-cur_master_commit = "unknown"
-
-if os.path.exists(get_build_dir() + 
"/upgrade-helper/last_checkpkg_run"):
-with open(get_build_dir() + "/upgrade-helper/last_checkpkg_run") 
as last_check:
-line = last_check.read()
-last_date_checked = line.split(',')[0]
-last_master_commit = line.split(',')[1]
-last_checkpkg_file = line.split(',')[2]
-if not os.path.exists(last_checkpkg_file):
-last_checkpkg_file = None
-
-if last_master_commit != cur_master_commit or last_date_checked != 
current_date or \
-last_checkpkg_file is None:
-self._check_upstream_versions()
-last_checkpkg_file = os.path.realpath(get_build_dir() + 
"/tmp/log/checkpkg.csv")
-else:
-I(" Using last checkpkg.csv file since last master commit and last"
-  " check date are the same ...")
+self._check_upstream_versions()
+last_checkpkg_file = os.path.realpath(get_build_dir() + 
"/tmp/log/checkpkg.csv")
 
 pkgs_list = []
 for pkg in self._parse_checkpkg_file(last_checkpkg_file):
 if self._pkg_upgradable(pkg[0], pkg[1], pkg[2]):
 pkgs_list.append(pkg)
 
-# Update last_checkpkg_run only after the version check has been 
completed
-with open(get_build_dir() + "/upgrade-helper/last_checkpkg_run", "w+") 
as last_check:
-last_check.write(current_date + "," + cur_master_commit + "," +
- last_checkpkg_file)
-
 return pkgs_list
 
 def _update_history(self, pn, new_ver, maintainer, upgrade_status):
-- 
2.15.0

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


[yocto] [auh][PATCH 00/20] Porting AUH to devtool and making it suitable for local use

2017-12-14 Thread Alexander Kanavin
This patchset replaces custom recipe rewriting code in AUH with calls to 
devtool and
makes other improvements aimed at making it suitable for local, interactive use 
by
recipe maintainers.

The following changes since commit ccf93239c7def7b475fe20f8fcd91043bc59bd61:

  upgradehelper.py: Layer mode do a full cleanup of poky (2017-06-05 16:14:23 
-0500)

are available in the Git repository at:

  git://github.com/kanavin/auh-devtool devel
  https://github.com/kanavin/auh-devtool/tree/devel

Alexander Kanavin (20):
  upgradehelper.py: do not error out if testimage or buildhistory are
enabled in bitbake conf, but not in AUH conf
  upgradehelper.py: always run checkpkg
  upgradehelper.py: do not manipulate git branches.
  upgradehelper.py: support updates to a new vcs revision.
  upgradehelper.py: add the old recipe version in pkg_ctx
  Add devtool support for upgrading recipes
  buildhistory.py: replace cleanall with cleansstate
  testimage.py: do not manipulate branches
  Replace references to Aníbal Limón as the maintainer.
  modules/recipe: remove
  upgradehelper.py: remove the package ordering code
  utils/git.py: print current dir when git fails
  testimage.py: do not call into removed code
  testimage.py: add extra logging for the testimage logs retrieval
  upgradehelper.py: fixups to the email message template
  upgradehelper.py: send email even if recipe upgrade failed
  upgradehelper.py: add all changes before committing them
  upgradehelper.py: when attempting to commit changes do not discard
previous errors
  upgradehelper.py: when recovering from upgrade error, do not refer to
a dict entry that may not exist
  upgradehelper.py: revert commits that failed to build

 README |   2 +-
 modules/buildhistory.py|   2 +-
 modules/errors.py  |   7 +-
 modules/recipe/__init__.py |   0
 modules/recipe/base.py | 724 -
 modules/recipe/git.py  |  98 --
 modules/recipe/svn.py  |  28 --
 modules/steps.py   | 191 ++--
 modules/testimage.py   |  46 +--
 modules/utils/devtool.py   |  41 +++
 modules/utils/git.py   |   8 +-
 upgradehelper.py   | 254 
 12 files changed, 208 insertions(+), 1193 deletions(-)
 delete mode 100644 modules/recipe/__init__.py
 delete mode 100644 modules/recipe/base.py
 delete mode 100644 modules/recipe/git.py
 delete mode 100644 modules/recipe/svn.py
 create mode 100644 modules/utils/devtool.py

-- 
2.15.0

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


[yocto] [auh][PATCH 01/20] upgradehelper.py: do not error out if testimage or buildhistory are enabled in bitbake conf, but not in AUH conf

2017-12-14 Thread Alexander Kanavin
From: Alexander Kanavin 

Signed-off-by: Alexander Kanavin 
---
 upgradehelper.py | 12 
 1 file changed, 12 deletions(-)

diff --git a/upgradehelper.py b/upgradehelper.py
index 8e5466e..1356aef 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -240,12 +240,6 @@ class Updater(object):
   " but isn't INHERIT in conf/local.conf, if you want"\
   " to enable please set.")
 exit(1)
-else:
-if 'buildhistory' in self.base_env['INHERIT']:
-E(" Buildhistory was INHERIT in conf/local.conf"\
-  " but buildhistory=yes isn't in upgrade-helper.conf,"\
-  " if you want to enable please set.")
-exit(1)
 
 return enabled
 
@@ -280,12 +274,6 @@ class Updater(object):
   " but isn't INHERIT in conf/local.conf, if you want"\
   " to enable please set.")
 exit(1)
-else:
-if 'testimage' in self.base_env['INHERIT']:
-E(" testimage was INHERIT in conf/local.conf"\
-  " but testimage=yes isn't in upgrade-helper.conf,"\
-  " if you want to enable please set.")
-exit(1)
 
 return enabled
 
-- 
2.15.0

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


[yocto] Ownership issues in rootfs but not in rpms

2017-12-14 Thread felix.lelc...@gmx.de
Hi everyone,

I'm trying to set up my Jethro based Distro in such way that a daemon gets its 
own user and group to run as.

The user and group are both created properly.
I also have the files and directories chowned in the same manner 
useradd-example does in do_install.
The rootfs however always contains root:root owned files/dirs. Looking into the 
RPM packages however, ownership is well as expected.

Note that I manually added useradd-example to my image with the same results.

Is there a reason you can think of that causes this? A known bug?
I would like to know how the ownership and permissions are considered when the 
image is created (are they virtual at build time due to peudo and do they 
become actual when the image is created?)
If this is documented somewhere I'd really appreciate a link.

Thank you!

Regards

Felix


Von meinem Huawei-Mobiltelefon gesendet
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] [meta-raspberrypi] linux kernel rt

2017-12-14 Thread Andreas Müller
On Thu, Dec 14, 2017 at 11:40 AM, Mirza Krak  wrote:

> 2017-12-14 9:41 GMT+01:00 Andreas Müller :
> > On Thu, Dec 14, 2017 at 2:58 AM, Sherif Omran  >
> > wrote:
> >>
> >> hey guys,
> >>
> >> any body tried the real time kernel? I get an error, it is snot in the
> >> compatibility list.
> >> can we skip it?
> >>
> >> thanks
> >>
> >> --
> >
> > Good news: I use RT kernel only together with VC4 graphics and have lots
> of
> > fun on PI2/3.
> > Bad news: As far as I know it is not in meta-raspberrypi but in my fork
> [1].
> > There were attempts to land the RT-patches in meta-raspberrypi but that
> was
> > denied for huge patch size :(
>
> If the patch size was the only problem one can pull it by doing the
> following in the recipe:
>
> SRC_URI += " \
> https://cdn.kernel.org/pub/linux/kernel/projects/rt/4.9/
> patch-4.9.65-rt56.patch.gz;name=rt-patch
> \
> "
>
> SRC_URI[rt-patch.md5sum] = "9caa7b541d8c84c2d5c5f58985982e95"
> SRC_URI[rt-patch.sha256sum] =
> "47dfb518c78d8cbaafd4ab9130eb26fe0170be9189b580ab26209ef679309539"
>
> Note that above sums are "random" and not the for the actually file
> but are there for reference.
>
> That way you do not need to keep a copy of it in meta-raspberrypi.
>
> --
>
Hi Mirza,

Problem is that patches need alignments sometimes either caused by
Raspberry-Pi-specific adjustments or versions not matching exactly - RT
kernel patch updates are less frequent than kernel updates. Anyway: git is
very good at maintaining huge text content and this should not be a problem
these days. Another discussion about RT kernel was to have an extra kernel
for it and I never understood why. To me that seems nothing but an extra
maintenance burden.

However - just wrote to Paul: I plan to be at FOSDEM and we can discuss
there how to get back to one layer only (not mine!) making everybody happy
:)

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


[yocto] Kernel size above KERNEL_IMAGE_MAXSIZE

2017-12-14 Thread Jaap de Jong

Hi All,
not sure if I should put this here.
If I define KERNEL_IMAGE_MAXSIZE below my actual kernel size I get this 
ugly error:


ERROR: linux-at91-4.9.28-r0.4 do_sizecheck: Function failed: 
do_sizecheck (log file is located at 
xxx/linux-at91/4.9.28-r0.4/temp/log.do_sizecheck.1370)
ERROR: Logfile of failure stored in: 
xxx/linux-at91/4.9.28-r0.4/temp/log.do_sizecheck.1370

Log data follows:
| DEBUG: Executing shell function do_sizecheck
| xxx/linux-at91/4.9.28-r0.4/temp/run.do_sizecheck.1370: line 117: warn: 
command not found
| WARNING: xxx/linux-at91/4.9.28-r0.4/temp/run.do_sizecheck.1370:1 exit 
127 from 'warn "This kernel $type (size=$size(K) > 2100(K)) is too big 
for your device. Please reduce the size of the kernel by making more of 
it modular."'
| ERROR: Function failed: do_sizecheck (log file is located at 
xxx/linux-at91/4.9.28-r0.4/temp/log.do_sizecheck.1370)
ERROR: Task 
(xxx/meta-atmel/recipes-kernel/linux/linux-at91_4.9.bb:do_sizecheck) 
failed with exit code '1'
NOTE: Tasks Summary: Attempted 1646 tasks of which 1638 didn't need to 
be rerun and 1 failed.


Summary: 1 task failed:
  xxx/meta-atmel/recipes-kernel/linux/linux-at91_4.9.bb:do_sizecheck
Summary: There was 1 ERROR message shown, returning a non-zero exit code.

Either poky/meta/classes/kernel.bbclass should be changed to run 'die' 
instead of 'warn' or in poky/meta/classes/base.bbclass a function 'warn' 
should be added. Not sure which. I tend to the first option: if the 
kernel image is too large then this is an error.


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


Re: [yocto] Permission denied while building rocko on Debian 8

2017-12-14 Thread Zoran Stojsavljevic
You might try also to post the same question in basic form here:
http://forums.debian.net

Zoran

On Thu, Dec 14, 2017 at 7:53 AM, Mircea Gliga 
wrote:

> Hi list
>
> See below
>
> On 11/12/17 15:22, Mircea Gliga wrote:
>
>>
>>
>> On 11/12/17 15:06, Paul Barker wrote:
>>
>>> On Mon, Dec 11, 2017 at 12:43 PM, Mircea Gliga 
>>> wrote:
>>>
 So I went further and I tested in a VM running Debian 9 - there it
 works:
 It looks like I get a Permission denied while building rocko only on
 Debian
 8, *not* on Debian 9.

 Debian 8 is listed as supported on Yocto Project Reference Manual  here:
 http://www.yoctoproject.org/docs/2.4/ref-manual/ref-manual.
 html#detailed-supported-distros
 Can somebody confirm this behavior ? It's a straight forward test:

 $ git clone -b rocko git://git.yoctoproject.org/poky.git
 $ source poky/oe-init-build-env
 $ bitbake core-image-minimal

>>> This looks like a weird permission issue rather than something
>>> Yocto-related. How are you running your Debian 8 system? Is it bare
>>> metal, VM, container, some hosting providers VPS, etc?
>>>
>> Indeed, the problem on the Debian 8 machine was that the following
> command was run sometime in the past - we needed a python service to listen
> on a privileged port:
> $ sudo setcap 'cap_net_bind_service=+ep' '/usr/bin/python3.5'
>
> Doing a setcap -r /usr/bin/python3.5 fixes the problem.
>
> So it has nothing to do with Yocto!
>
> Thanks for support.
>
>
> Debian 8 is running on a real system, no VM etc.
>> I used netinstall with no desktop environment and without all the blows
>> and whistles and added just what I needed, when I needed it.
>> This machine was used for the last 1,5 years or so for developing on
>> Krogoth.
>> I was able to reproduce the problem on a second box, real machine,
>> running Debian 8
>>
>> Meanwhile I tried building rocko on another real machine, running Debian
>> 9 - it works. ( in the prev email I tested in a Debian 9 VM)
>>
>> Thanks
>>
>>
 PS I've updated the thread subject to better reflect the problem.

 Thanks

 On 11/12/17 09:58, Mircea Gliga wrote:

 Hello,

 I have a working krogoth build - I build images etc, everything is fine.
 Then I wanted to try a rocko build, I installed the needed host
 packages:
 http://www.yoctoproject.org/docs/2.4/yocto-project-qs/yocto-
 project-qs.html#packages
 Then sourced env and bitbake core-image-minimal.
 So no extra layers involved, just poky.
 I get errors like this:

 ERROR: gnu-config-native-20150728+gitAUTOINC+b576fa87c1-r0 do_fetch:
 Build
 of do_fetch failed
 ERROR: gnu-config-native-20150728+gitAUTOINC+b576fa87c1-r0 do_fetch:
 Traceback (most recent call last):
File
 "/media/mircea/ExtLinux/Adventure/repository/rocko/poky/bitbake/lib/bb/build.py",

 line 644, in exec_task
  return _exec_task(fn, task, d, quieterr)
File
 "/media/mircea/ExtLinux/Adventure/repository/rocko/poky/bitbake/lib/bb/build.py",

 line 618, in _exec_task
  event.fire(TaskSucceeded(task, logfn, localdata), localdata)
File
 "/media/mircea/ExtLinux/Adventure/repository/rocko/poky/bitbake/lib/bb/event.py",

 line 222, in fire
  fire_class_handlers(event, d)
File
 "/media/mircea/ExtLinux/Adventure/repository/rocko/poky/bitbake/lib/bb/event.py",

 line 134, in fire_class_handlers
  execute_handler(name, handler, event, d)
File
 "/media/mircea/ExtLinux/Adventure/repository/rocko/poky/bitbake/lib/bb/event.py",

 line 106, in execute_handler
  ret = handler(event)
File
 "/media/mircea/ExtLinux/Adventure/repository/rocko/poky/
 meta/classes/buildstats.bbclass",
 line 166, in run_buildstats
  write_task_data("passed", os.path.join(taskdir, e.task), e, d)
File
 "/media/mircea/ExtLinux/Adventure/repository/rocko/poky/
 meta/classes/buildstats.bbclass",
 line 90, in write_task_data
  cpu, iostats, resources, childres = get_process_cputime(os.getpid(
 ))
File
 "/media/mircea/ExtLinux/Adventure/repository/rocko/poky/
 meta/classes/buildstats.bbclass",
 line 29, in get_process_cputime
  with open("/proc/%d/io" % pid, "r") as f:
 PermissionError: [Errno 13] Permission denied: '/proc/1530/io'

 ERROR: Task
 (virtual:native:/media/mircea/ExtLinux/Adventure/repository/
 rocko/poky/meta/recipes-devtools/gnu-config/gnu-config_git.bb:do_fetch)

 failed with exit code '1'
 ERROR: autoconf-native-2.69-r11 do_fetch: Execution of event handler
 'run_buildstats' failed
 Traceback (most recent call last):
File
 "/media/mircea/ExtLinux/Adventure/repository/rocko/poky/
 meta/classes/buildstats.bbclass",
 line 166, in run_buildstats(e=>>> 

Re: [yocto] [meta-raspberrypi] linux kernel rt

2017-12-14 Thread Mirza Krak
2017-12-14 9:41 GMT+01:00 Andreas Müller :
> On Thu, Dec 14, 2017 at 2:58 AM, Sherif Omran 
> wrote:
>>
>> hey guys,
>>
>> any body tried the real time kernel? I get an error, it is snot in the
>> compatibility list.
>> can we skip it?
>>
>> thanks
>>
>> --
>
> Good news: I use RT kernel only together with VC4 graphics and have lots of
> fun on PI2/3.
> Bad news: As far as I know it is not in meta-raspberrypi but in my fork [1].
> There were attempts to land the RT-patches in meta-raspberrypi but that was
> denied for huge patch size :(

If the patch size was the only problem one can pull it by doing the
following in the recipe:

SRC_URI += " \

https://cdn.kernel.org/pub/linux/kernel/projects/rt/4.9/patch-4.9.65-rt56.patch.gz;name=rt-patch
\
"

SRC_URI[rt-patch.md5sum] = "9caa7b541d8c84c2d5c5f58985982e95"
SRC_URI[rt-patch.sha256sum] =
"47dfb518c78d8cbaafd4ab9130eb26fe0170be9189b580ab26209ef679309539"

Note that above sums are "random" and not the for the actually file
but are there for reference.

That way you do not need to keep a copy of it in meta-raspberrypi.

-- 
Med Vänliga Hälsningar / Best Regards

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


Re: [yocto] [meta-raspberrypi] linux kernel rt

2017-12-14 Thread Paul D. DeRocco
> > On Thu, Dec 14, 2017 at 2:58 AM, Sherif Omran 
> >  wrote:
> > 
> > any body tried the real time kernel? I get an error, it 
> > is snot in the compatibility list.
> 
> From: Andreas Müller
> 
> Good news: I use RT kernel only together with VC4 graphics 
> and have lots of fun on PI2/3. 
> 
> Bad news: As far as I know it is not in meta-raspberrypi but 
> in my fork [1]. There were attempts to land the RT-patches in 
> meta-raspberrypi but that was denied for huge patch size :(

I can vouch for this. I've been using meta-raspi-light for a while on an RPi3, 
doing music synthesis, and pushing all four cores to about 90% utilization, 
running the OS "in the cracks", and it's been solid. Thanks, Andreas.

-- 

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

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


Re: [yocto] [meta-raspberrypi] linux kernel rt

2017-12-14 Thread Andreas Müller
On Thu, Dec 14, 2017 at 2:58 AM, Sherif Omran 
wrote:

> hey guys,
>
> any body tried the real time kernel? I get an error, it is snot in the
> compatibility list.
> can we skip it?
>
> thanks
>
> --
>
Good news: I use RT kernel only together with VC4 graphics and have lots of
fun on PI2/3.
Bad news: As far as I know it is not in meta-raspberrypi but in my fork
[1]. There were attempts to land the RT-patches in meta-raspberrypi but
that was denied for huge patch size :(

[1] https://github.com/schnitzeltony/meta-raspi-light/tree/master/recipes-
kernel/linux

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


[yocto] [meta-security][PATCH] xmlsec1: fix invalid paths in target xmlsec1Conf.sh

2017-12-14 Thread Ovidiu Panait
Remove build host paths from target xmlsec1Conf.sh script.

Signed-off-by: Catalin Enache 
Signed-off-by: Ovidiu Panait 
---
 recipes-security/xmlsec1/xmlsec1_1.2.24.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/recipes-security/xmlsec1/xmlsec1_1.2.24.bb 
b/recipes-security/xmlsec1/xmlsec1_1.2.24.bb
index 9798ce2..1f7fbd3 100644
--- a/recipes-security/xmlsec1/xmlsec1_1.2.24.bb
+++ b/recipes-security/xmlsec1/xmlsec1_1.2.24.bb
@@ -46,6 +46,7 @@ do_compile_ptest () {
 
 do_install_append() {
 sed -i -e "s@${STAGING_DIR_HOST}@@g" ${D}${bindir}/xmlsec1-config
+sed -e "s@${STAGING_DIR_HOST}@@g" -i ${D}${libdir}/xmlsec1Conf.sh
 }
 
 do_install_ptest () {
-- 
2.10.2

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


[yocto] [meta-raspberrypi] bluetooth device not available with rpi0w

2017-12-14 Thread Sherif Omran
guys,
i tried to get the bluetooth to work but i get no default controller
available
hciconfig hci0 -> does not find the device
i installed it with rpi-basic-image

do i need to flash the bluetooth intell firmware?

could you please help !
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] recipe to clean up files from rootfs

2017-12-14 Thread Sherif Omran
hi Andre
thank you for your mail. I tried to remove this package but i don't know
where it is installed from, i can not find it and got lost.

On Thu, Dec 14, 2017 at 9:11 AM, Sherif Omran 
wrote:

> hi Martin,
>
> thank you for help .. well done .. it should now work..
>
> On Thu, Dec 14, 2017 at 8:17 AM, Martin Hundebøll <
> martin.hundeb...@prevas.dk> wrote:
>
>> Hi Sherif,
>>
>> On 2017-12-14 08:06, Sherif Omran wrote:
>>
>>> Here is my recipe, it runs suceeds but does not delete the files
>>>
>>> mypostprocesfunction() {
>>> rm -r ${IMAGE_ROOTFS}/etc/init.d/psplash.sh
>>> rm -r ${IMAGE_ROOTFS}/usr/bin/psplash*
>>> }
>>>
>>> ROOTFS_POSTPROCESS_COMMAND += "mypostprocessfunction; "
>>>
>>
>> Unless you did a copy-paste error, there's a typo in the function name:
>> mypostprocesfunction
>> mypostprocessfunction
>>
>> // Martin
>>
>>
>>> On Wed, Dec 13, 2017 at 2:03 PM, Mike Looijmans >> > wrote:
>>>
>>> ${D} won't work here, grep on ROOTFS_POSTPROCESS_COMMAND for recipes
>>> that get it right.
>>>
>>> And, much much much better would be to just not install psplash into
>>> your image!
>>>
>>> On 13-12-17 09:10, Sherif Omran wrote:
>>>
>>> here is my recipe, the aim was to remove some files from the
>>> init.d folder and tweek before creating the image
>>>
>>> #
>>> # This file was derived from the 'Hello World!' example recipe
>>> in the
>>> # Yocto Project Development Manual.
>>> #
>>>
>>> SUMMARY = "This recipe removes any missing files from the
>>> filesystem before finalinzing it"
>>> SECTION = "base"
>>> LICENSE = "MIT"
>>> LIC_FILES_CHKSUM =
>>> "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecd
>>> a2f7b4f302"
>>>
>>> #SRC_URI = "file://*"
>>>
>>> S = "${WORKDIR}"
>>> BB_STRICT_CHECKSUM ="0"
>>> ALLOW_EMPTY_${PN}="1"
>>>
>>>
>>> #IMAGE_INSTALL = "packagegroup-core-boot
>>> packagegroup-base-extended ${CORE_IMAGE_EXTRA_INSTALL}"
>>> #IMAGE_INSTALL = "${CORE_IMAGE}"
>>>
>>> #inherit core-image
>>>
>>> my_postprocess_function() {
>>>rm -r ${D}${bindir}/init.d/psplash.sh
>>> }
>>>
>>> ROOTFS_POSTPROCESS_COMMAND += "my_postprocess_function; "
>>>
>>> On Wed, Dec 13, 2017 at 7:22 AM, Mike Looijmans
>>> 
>>> >> >> wrote:
>>>
>>>  Well, start by sharing yours first.
>>>
>>>  Be careful when naming your shell routine, sometimes OE
>>> considers parts
>>>  behind the underscore as overrides and then it cannot find
>>> it.
>>>
>>>
>>>  On 13-12-17 07:14, Sherif Omran wrote:
>>>
>>>  hi Mike,
>>>  i could not get it to work, if you have a recipe that
>>> works, please
>>>  share it. ROOTFS_POSTPROCESS_COMMAND seems to be buggy.
>>>
>>>  thank you
>>>
>>>
>>>
>>>  On Tue, Dec 12, 2017 at 1:58 PM, Mike Looijmans
>>>  >>  >> >
>>>  >>  >> >>
>>>   On 11-12-17 15:18, Sherif Omran wrote:
>>>
>>>   i want to create a recipe to clean some files
>>> from the rootfile
>>>   system, but i don't know how to let this
>>> recipe run the last one
>>>   before building the rootfile system.
>>>
>>>
>>>   You can use ROOTFS_POSTPROCESS_COMMAND in your
>>> image recipe to do
>>>  some
>>>   last-minute filesystem cleanup.
>>>
>>>   However, in most cases it's much better to
>>> determine what recipe
>>>  puts the
>>>   files there and modify the recipe or remove the
>>> package. It would
>>>  help a
>>>   lot if you would reveal what files you want to
>>> remove and why.
>>>
>>>
>>>   Kind regards,
>>>
>>>   Mike Looijmans
>>>   System Expert
>>>
>>>   TOPIC Products
>>>   Materiaalweg 4, NL-5681 RJ Best
>>>   Postbus 440, NL-5680 AK Best
>>>   Telefoon: +31 (0) 499 33 69 79
>>> 
>>>  

Re: [yocto] recipe to clean up files from rootfs

2017-12-14 Thread Sherif Omran
hi Martin,

thank you for help .. well done .. it should now work..

On Thu, Dec 14, 2017 at 8:17 AM, Martin Hundebøll <
martin.hundeb...@prevas.dk> wrote:

> Hi Sherif,
>
> On 2017-12-14 08:06, Sherif Omran wrote:
>
>> Here is my recipe, it runs suceeds but does not delete the files
>>
>> mypostprocesfunction() {
>> rm -r ${IMAGE_ROOTFS}/etc/init.d/psplash.sh
>> rm -r ${IMAGE_ROOTFS}/usr/bin/psplash*
>> }
>>
>> ROOTFS_POSTPROCESS_COMMAND += "mypostprocessfunction; "
>>
>
> Unless you did a copy-paste error, there's a typo in the function name:
> mypostprocesfunction
> mypostprocessfunction
>
> // Martin
>
>
>> On Wed, Dec 13, 2017 at 2:03 PM, Mike Looijmans > > wrote:
>>
>> ${D} won't work here, grep on ROOTFS_POSTPROCESS_COMMAND for recipes
>> that get it right.
>>
>> And, much much much better would be to just not install psplash into
>> your image!
>>
>> On 13-12-17 09:10, Sherif Omran wrote:
>>
>> here is my recipe, the aim was to remove some files from the
>> init.d folder and tweek before creating the image
>>
>> #
>> # This file was derived from the 'Hello World!' example recipe
>> in the
>> # Yocto Project Development Manual.
>> #
>>
>> SUMMARY = "This recipe removes any missing files from the
>> filesystem before finalinzing it"
>> SECTION = "base"
>> LICENSE = "MIT"
>> LIC_FILES_CHKSUM =
>> "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecd
>> a2f7b4f302"
>>
>> #SRC_URI = "file://*"
>>
>> S = "${WORKDIR}"
>> BB_STRICT_CHECKSUM ="0"
>> ALLOW_EMPTY_${PN}="1"
>>
>>
>> #IMAGE_INSTALL = "packagegroup-core-boot
>> packagegroup-base-extended ${CORE_IMAGE_EXTRA_INSTALL}"
>> #IMAGE_INSTALL = "${CORE_IMAGE}"
>>
>> #inherit core-image
>>
>> my_postprocess_function() {
>>rm -r ${D}${bindir}/init.d/psplash.sh
>> }
>>
>> ROOTFS_POSTPROCESS_COMMAND += "my_postprocess_function; "
>>
>> On Wed, Dec 13, 2017 at 7:22 AM, Mike Looijmans
>> 
>> > >> wrote:
>>
>>  Well, start by sharing yours first.
>>
>>  Be careful when naming your shell routine, sometimes OE
>> considers parts
>>  behind the underscore as overrides and then it cannot find
>> it.
>>
>>
>>  On 13-12-17 07:14, Sherif Omran wrote:
>>
>>  hi Mike,
>>  i could not get it to work, if you have a recipe that
>> works, please
>>  share it. ROOTFS_POSTPROCESS_COMMAND seems to be buggy.
>>
>>  thank you
>>
>>
>>
>>  On Tue, Dec 12, 2017 at 1:58 PM, Mike Looijmans
>>  >  > >
>>  >  > >
>>   On 11-12-17 15:18, Sherif Omran wrote:
>>
>>   i want to create a recipe to clean some files
>> from the rootfile
>>   system, but i don't know how to let this
>> recipe run the last one
>>   before building the rootfile system.
>>
>>
>>   You can use ROOTFS_POSTPROCESS_COMMAND in your
>> image recipe to do
>>  some
>>   last-minute filesystem cleanup.
>>
>>   However, in most cases it's much better to
>> determine what recipe
>>  puts the
>>   files there and modify the recipe or remove the
>> package. It would
>>  help a
>>   lot if you would reveal what files you want to
>> remove and why.
>>
>>
>>   Kind regards,
>>
>>   Mike Looijmans
>>   System Expert
>>
>>   TOPIC Products
>>   Materiaalweg 4, NL-5681 RJ Best
>>   Postbus 440, NL-5680 AK Best
>>   Telefoon: +31 (0) 499 33 69 79
>> 
>>  
>>  
>>   E-mail: mike.looijm...@topicproducts.com
>> 
>>  > >
>>