date:20140821

Re: [yocto] Kernel driver for Turbosight TBS6285 DVB card

2014-08-21 Thread Chris Tapp


On 21 Aug 2014, at 05:08, Bruce Ashfield  wrote:

> On Wed, Aug 20, 2014 at 4:11 PM, Chris Tapp  wrote:
>> Hi Bruce,
>> 
>> Thanks for the feedback.
>> 
>> On 20 Aug 2014, at 03:08, Bruce Ashfield  
>> wrote:
>> 
>>> On 2014-08-19, 5:26 PM, Chris Tapp wrote:
 I need to include the kernel driver for the Turbosight TBS6285 DVB card in 
 an image.
 
 The official bundle at 
 http://www.tbsdtv.com/download/document/common/tbs-linux-drivers_v140707.zip
  includes the drivers and a load of other "stuff" (e.g. a full V4L build).
 
 LinuxTV.org have the drivers extracted into a .tar.bz2 at (e.g.) 
 http://linuxtv.org/downloads/drivers/linux-media-LATEST.tar.bz2, so I plan 
 to use this as the download source.
>> 
>> This bit is wrong - I need to use the .tar.bz within the .zip.
>> 
 
 So far I have a recipe which downloads from this URL and extracts the 
 files into the work area and ${WORKAREA}/drivers/media includes a Makefile 
 and Kconfig.
 
 I've looked at the Yocto documentation, but this doesn't seem to be a good 
 match for the "Out of tree" kernel module case.
>>> 
>>> Hmm. At a glance, I'd say that it does sound like a typical out of
>>> tree module build.
>> 
>> Ah, ok - to my (untrained) eye the use-case looked completely different 
>> based on the example.
>> 
>>> Did you try adopting the meta-skeleton hello-mod recipe and point it
>>> at that source directory ?
>> 
>> I have now (with the above change). However, it looks as if something within 
>> the build is referencing the host file system when building.
>> 
>> I'm building for ValleyIsland 32-bit:
>> 
>>  1) If I configure the drivers for 32-bit there is a linker error 
>> complaining that elf 32 and elf 64 aren't compatible (host is 64 bit);
> 
> Hmm. The target arch should be used for this build. Are you enabling a
> multi lib config
> as well ?

Not that I know of ;-)

The build uses a .version file to specify the kernel. The top makefile creates 
this using 'uname -r' by default. I can run 'make dir DIR="..." in 
do_configure() to specify the path to the yocto kernel files, which seems to 
fix this (after modifying another makefile, which prepends "../" to the DIR 
path).

>  2) Everything appears to build if I target 64-bit, but the installer tries 
> to modify /lib/modules/3.2.0-67/..., which is also part of the host.
> 
> Do the Makefile's that come in that archive (I haven't gone to look)
> have a custom
> install rule ? If so, that's likely the problem. If the kernel's build
> system is triggered
> (i.e. the makefile follows the conventions), everything will be
> installed to the proper
> location.

The installer uses DESTDIR to select the installation path - I've not worked 
out how this gets set yet or how I can set it from within my recipe.

Is there a trick I can use to get the kernel's build system to manage things?

> 
> Bruce
> 
>> 
>> Looks like I need a patch ;-) Any pointers to where I should be looking 
>> would be appreciated as this isn't my normal area...
>> 
>> --
>> 
>> Chris Tapp
>> opensou...@keylevel.com
>> www.keylevel.com
>> 
>> 
>> 
>> 
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
> 
> 
> 
> -- 
> "Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end"

--

Chris Tapp
opensou...@keylevel.com
www.keylevel.com




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

Re: [yocto] Setting Default User Accounts

2014-08-21 Thread ChenQi


How about add in local.conf:

INHERIT += "extrausers"
EXTRA_USERS_PARAMS = "usermod -L root; \
  useradd -P 'test' test;"

//Chen Qi

On 08/21/2014 03:13 AM, Crast, Nicholas wrote:


All,

I am currently in the middle of a battle with yocto, trying to 
accomplish the following:


1.)Disable root user account

2.)Create default user account with default password

I currently have the following a recipe:

USERADD_PACKAGES = "${PN}"

USERADD_PARAM_${PN} = "-d /home/nick -r -s /bin/bash nick "

In order to try to add a user account. I have this in my image recipe:

ROOTFS_POSTPROCESS_COMMAND += "set_nick_passwd;"

set_nick_passwd() {

   sed 's%^ nick:[^:]*:% nick:adySxRKMiPvjA:%' \

   < ${IMAGE_ROOTFS}/etc/shadow \

   > ${IMAGE_ROOTFS}/etc/shadow.new;

   mv ${IMAGE_ROOTFS}/etc/shadow.new ${IMAGE_ROOTFS}/etc/shadow ;

}

This is to edit the /etc/shadow file and insert a new (hashed) 
password. What I’m looking for is a cleaner way to do this. When I run 
bitbake I get a lot of warnings because the “nick” account is already 
an account on my build machine. This seems like a fairly common use 
case, and I think I am likely going about it wrong.


Does anybody have any advice?

-Nick



Nick Crast

Associate Software Engineer

Saab Sensis Corporation

Phone: 315-445-5703

Email: nicholas.cr...@saabsensis.com 




/This message is intended only for the addressee and may contain 
information that is company confidential or privileged. Any technical 
data in this message may be exported only in accordance with the U.S. 
International Traffic in Arms Regulations (22 CFR Parts 120-130) or 
the Export Administration Regulations (15 CFR Parts 730-774). 
Unauthorized use is strictly prohibited and may be unlawful. If you 
are not the intended recipient, or the person responsible for 
delivering to the intended recipient, you should not read, copy, 
disclose or otherwise use this message. If you have received this 
email in error, please delete it, and advise the sender immediately. /





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

[yocto] Tizen Build Using Yocto - bitbake error mesa_10.1.3.bb,do_configure

2014-08-21 Thread Anoop

Hi

Yocto Build for minimal image

Summary: 1 task failed:
  /home/sfm/YOCTO/poky/meta/recipes-graphics/mesa/mesa_10.1.3.bb, 
do_configure

*
configure: error: Package requirements (x11-xcb xcb-dri2 >= 1.8 xcb-xfixes) 
were not met:

No package 'x11-xcb' found
No package 'xcb-dri2' found
No package 'xcb-xfixes' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables XCB_DRI2_CFLAGS
and XCB_DRI2_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.

+ '[' 1 '!=' 0 ']'
+ echo 'Configure failed. The contents of all config.log files follows to 
aid debugging'
Configure failed. The contents of all config.log files follows to aid 
debugging
+ find /home/sfm/YOCTO/build/tmp/work/cortexa9hf-vfp-neon-mx6-poky-linux-
gnueabi/mesa/2_10.1.3-r0/Mesa-10.1.3 -name config.log -print -exec cat '{}' 
';'

+ bbfatal 'oe_runconf failed'
+ echo 'ERROR: oe_runconf failed'
ERROR: oe_runconf failed
+ exit 1
+ bb_exit_handler
+ ret=1
+ case $ret in
+ case $BASH_VERSION in
+ echo 'WARNING: /home/sfm/YOCTO/build/tmp/work/cortexa9hf-vfp-neon-mx6-
poky-linux-gnueabi/mesa/2_10.1.3-r0/temp/run.do_configure.12232:1 exit 1 
from
  exit' 1
WARNING: /home/sfm/YOCTO/build/tmp/work/cortexa9hf-vfp-neon-mx6-poky-linux-
gnueabi/mesa/2_10.1.3-r0/temp/run.do_configure.12232:1 exit 1 from
  exit 1
+ exit 1

CTO/build/tmp/sysroots/i686-linux/usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking whether arm-poky-linux-gnueabi-gcc  -march=armv7-a -mthumb-
interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 --
sysroot=/home/sfm/YOCTO/build/tmp/sysroots/imx6qsabreauto supports -
Werror=missing-prototypes... yes
checking whether arm-poky-linux-gnueabi-gcc  -march=armv7-a -mthumb-
interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 --
sysroot=/home/sfm/YOCTO/build/tmp/sysroots/imx6qsabreauto supports -
fvisibility=hidden... yes
checking whether arm-poky-linux-gnueabi-g++  -march=armv7-a -mthumb-
interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 --
sysroot=/home/sfm/YOCTO/build/tmp/sysroots/imx6qsabreauto supports -
fvisibility=hidden... yes
checking whether C compiler accepts -msse4.1... no
checking whether to enable assembly... no, platform not supported
checking for dlopen... no
checking for dlopen in -ldl... yes
checking for clock_gettime... yes
checking for posix_memalign... (cached) yes
checking for the pthreads library -lpthreads... no
checking whether pthreads work without any flags... no
checking whether pthreads work with -Kthread... no
checking whether pthreads work with -kthread... no
checking for the pthreads library -llthread... no
checking whether pthreads work with -pthread... yes
checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
checking if more special flags are required for pthreads... no
checking for PTHREAD_PRIO_INHERIT... no
configure: WARNING: GLX disabled, disabling Xlib-GLX
checking for LIBDRM... yes
checking for LIBUDEV... yes
checking for EXPAT... yes
checking for mincore... yes
checking for XCB_DRI2... no
configure: error: Package requirements (x11-xcb xcb-dri2 >= 1.8 xcb-xfixes) 
were not met:

No package 'x11-xcb' found
No package 'xcb-dri2' found
No package 'xcb-xfixes' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables XCB_DRI2_CFLAGS
and XCB_DRI2_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
+ '[' 1 '!=' 0 ']'
+ echo 'Configure failed. The contents of all config.log files follows to 
aid debugging'
Configure failed. The contents of all config.log files follows to aid 
debugging
+ find /home/sfm/YOCTO/build/tmp/work/cortexa9hf-vfp-neon-mx6-poky-linux-
gnueabi/mesa/2_10.1.3-r0/Mesa-10.1.3 -name config.log -print -exec cat '{}' 
';'
+ bbfatal 'oe_runconf failed'
+ echo 'ERROR: oe_runconf failed'
ERROR: oe_runconf failed
+ exit 1
+ bb_exit_handler
+ ret=1
+ case $ret in
+ case $BASH_VERSION in
+ echo 'WARNING: /home/sfm/YOCTO/build/tmp/work/cortexa9hf-vfp-neon-mx6-
poky-linux-gnueabi/mesa/2_10.1.3-r0/temp/run.do_configure.12232:1 exit 1 
from
  exit' 1
WARNING: /home/sfm/YOCTO/build/tmp/work/cortexa9hf-vfp-neon-mx6-poky-linux-
gnueabi/mesa/2_10.1.3-r0/temp/run.do_configure.12232:1 exit 1 from
  exit 1
+ exit 1
ERROR: Function failed: do_configure (log file is located at 
/home/sfm/YOCTO/build/tmp/work/cortexa9hf-vfp-neon-mx6-poky-linux-
gnueabi/mesa/2_10.1.3-r0/temp/log.do_configure.12232)

Please give inputs to resolve the error

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

[yocto] [PATCH 2/2] Kill suprocesses when pressing ctrl+c

2014-08-21 Thread Marius Avram

This way the created bitbake subprocesses from the upgrade script
are killed as well when you press ctrl+c.

Signed-off-by: Marius Avram 
---
 upgradehelper.py |6 ++
 1 file changed, 6 insertions(+)

diff --git a/upgradehelper.py b/upgradehelper.py
index 771c981..7db89a7 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -35,6 +35,7 @@ from logging import warning as W
 from logging import error as E
 from logging import critical as C
 import re
+import signal
 import sys
 import ConfigParser as cp
 from datetime import datetime
@@ -645,11 +646,16 @@ class UniverseUpdater(Updater):
 self.prepare()
 super(UniverseUpdater, self).run()
 
+def close_child_processes(signal_id, frame):
+pid = os.getpid()
+os.killpg(pid, signal.SIGKILL)
 
 if __name__ == "__main__":
 global settings
 global maintainer_override
 
+signal.signal(signal.SIGINT, close_child_processes)
+
 debug_levels = [log.CRITICAL, log.ERROR, log.WARNING, log.INFO, log.DEBUG]
 args = parse_cmdline()
 log.basicConfig(format='%(levelname)s:%(message)s',
-- 
1.7.9.5

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

[yocto] [PATCH 0/2] AUH patchset

2014-08-21 Thread Marius Avram

Two small features for the auto upgrade helper.
Contrib branch can be found here:
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mavram/auh_features

Marius Avram (2):
  Send emails for a list of recipes
  Kill suprocesses when pressing ctrl+c

 upgradehelper.py |  205 +++---
 1 file changed, 104 insertions(+), 101 deletions(-)

-- 
1.7.9.5

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

[yocto] [PATCH 1/2] Send emails for a list of recipes

2014-08-21 Thread Marius Avram

If the --emails or -e command line argument is active and a single
or a list of recipes are given to the script, emails with the results
and patches will be sent to their maintainers or to the overriden
addresses from the configuration file.

Also the status email will be sent in the case a selection of
at least two recipes has been given to the script for upgrading.

Signed-off-by: Marius Avram 
---
 upgradehelper.py |  199 +++---
 1 file changed, 98 insertions(+), 101 deletions(-)

diff --git a/upgradehelper.py b/upgradehelper.py
index cc90958..771c981 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -71,6 +71,8 @@ def parse_cmdline():
 help="disable interactive mode")
 parser.add_argument("-d", "--debug-level", type=int, default=4, 
choices=range(1, 6),
 help="set the debug level: CRITICAL=1, ERROR=2, 
WARNING=3, INFO=4, DEBUG=5")
+parser.add_argument("-e", "--emails", type=bool, default=False,
+help="send emails to recipe maintainers")
 parser.add_argument("-s", "--skip-compilation", action="store_true", 
default=False,
 help="do not compile, just change the checksums, 
remove PR, and commit")
 parser.add_argument("-c", "--config-file", default=None,
@@ -116,7 +118,27 @@ def parse_config_file(config_file):
 return (settings, maintainer_override)
 
 class Updater(object):
-def __init__(self, auto_mode=False, skip_compilation=False):
+mail_header = \
+"Hello,\n\nYou are receiving this email because you are the 
maintainer\n" \
+"of *%s* recipe and this is to let you know that the automatic 
attempt\n" \
+"to upgrade the recipe to *%s* has %s.\n\n"
+
+next_steps_info = \
+"The recipe has been successfully compiled for all major 
architectures.\n\n" \
+"Next steps:\n" \
+"- apply the patch: git am %s\n" \
+"- check that required patches have not been removed from the 
recipe\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" \
+
+mail_footer = \
+"Attached are the patch and the logs (+ license file diff) in case of 
failure.\n\n" \
+"Regards,\nThe Upgrade Helper"
+
+
+def __init__(self, auto_mode=False, send_email=False, 
skip_compilation=False):
 
 self.uh_dir = get_build_dir() + "/upgrade-helper"
 if not os.path.exists(self.uh_dir):
@@ -125,10 +147,10 @@ class Updater(object):
 self.bb = Bitbake(get_build_dir())
 self.buildhistory = BuildHistory(get_build_dir())
 self.git = None
-
-self.author = None
+self.author = "Upgrade Helper "
 self.skip_compilation = skip_compilation
 self.interactive = not auto_mode
+self.send_email = send_email
 
 self.machines = ["qemux86", "qemux86-64", "qemuarm", "qemumips", 
"qemuppc"]
 
@@ -144,6 +166,7 @@ class Updater(object):
 (self._compile, None)
 ]
 
+self.email_handler = Email(settings)
 self.statistics = Statistics()
 
 
@@ -307,8 +330,9 @@ class Updater(object):
 
 # this function will be called at the end of each recipe upgrade
 def pkg_upgrade_handler(self, err):
-if err is not None and self.patch_file is not None:
+if err and self.patch_file:
 answer = "N"
+status_msg = str(err)
 if self.interactive:
 I(" %s: Do you want to keep the changes? (y/N)" % self.pn)
 answer = sys.stdin.readline().strip().upper()
@@ -317,6 +341,53 @@ class Updater(object):
 I(" %s: Dropping changes from git ..." % self.pn)
 self.git.reset_hard(1)
 self.git.clean_untracked()
+return
+elif not err:
+status_msg = "Succeeded"
+
+status = type(err).__name__
+
+# drop last upgrade from git. It's safer this way if the upgrade has
+# problems and other recipes depend on it. Give the other recipes a
+# chance...
+if ("drop_previous_commits" in settings and
+settings["drop_previous_commits"] == "yes" and
+err) or (err and self.patch_file):
+I(" %s: Dropping changes from git ..." % self.pn)
+self.git.reset_hard(1)
+self.git.clean_untracked()
+
+if self.send_email:
+# don't bother maintainer with mail if the recipe is already up to 
date
+if status == "UpgradeNotNeededError":
+return
+
+if self.maintainer in maintainer_override:
+to_addr = maintainer_override[self.maintainer]
+else:
+to_addr = self.maintainer
+
+subjec

Re: [yocto] Setting Default User Accounts

2014-08-21 Thread Akash Bhatnagar

Hi I have added new user in following way:-

S = "${WORKDIR}"

inherit useradd

USERADD_PACKAGES = "${PN}"

USERADD_PARAM_${PN} = "-u 1200 -d /home/test -r -s /bin/bash -P 'test123'
test "


GROUPADD_PARAM_${PN} = "-g 880 testgrp"


do_install () {
install -d -m 755 ${D}/home/test

install -p -m 644  ${D}/home/test/

chown -R cli ${D}/home/test

chgrp -R cligrp ${D}/home/test
}

FILES_${PN} = "/home/test/* "

INHIBIT_PACKAGE_DEBUG_SPLIT = "1"





On Thu, Aug 21, 2014 at 3:51 PM, ChenQi  wrote:

>  How about add in local.conf:
>
> INHERIT += "extrausers"
> EXTRA_USERS_PARAMS = "usermod -L root; \
>   useradd -P 'test' test;"
>
> //Chen Qi
>
>
> On 08/21/2014 03:13 AM, Crast, Nicholas wrote:
>
>  All,
>
>
>
> I am currently in the middle of a battle with yocto, trying to accomplish
> the following:
>
>
>
> 1.)Disable root user account
>
> 2.)Create default user account with default password
>
>
>
> I currently have the following a recipe:
>
> USERADD_PACKAGES = "${PN}"
>
> USERADD_PARAM_${PN} = "-d /home/nick -r -s /bin/bash nick "
>
>
>
> In order to try to add a user account. I have this in my image recipe:
>
>
>
> ROOTFS_POSTPROCESS_COMMAND += "set_nick_passwd;"
>
> set_nick_passwd() {
>
>sed 's%^ nick:[^:]*:% nick:adySxRKMiPvjA:%' \
>
>< ${IMAGE_ROOTFS}/etc/shadow \
>
>> ${IMAGE_ROOTFS}/etc/shadow.new;
>
>mv ${IMAGE_ROOTFS}/etc/shadow.new ${IMAGE_ROOTFS}/etc/shadow ;
>
> }
>
>
>
> This is to edit the /etc/shadow file and insert a new (hashed) password.
> What I’m looking for is a cleaner way to do this. When I run bitbake I get
> a lot of warnings because the “nick” account is already an account on my
> build machine. This seems like a fairly common use case, and I think I am
> likely going about it wrong.
>
>
>
> Does anybody have any advice?
>
>
>
> -Nick
>
> 
>
> Nick Crast
>
> Associate Software Engineer
>
> Saab Sensis Corporation
>
> Phone: 315-445-5703
>
> Email: nicholas.cr...@saabsensis.com
>
>
>
> *This message is intended only for the addressee and may contain
> information that is company confidential or privileged. Any technical data
> in this message may be exported only in accordance with the U.S.
> International Traffic in Arms Regulations (22 CFR Parts 120-130) or the
> Export Administration Regulations (15 CFR Parts 730-774). Unauthorized use
> is strictly prohibited and may be unlawful. If you are not the intended
> recipient, or the person responsible for delivering to the intended
> recipient, you should not read, copy, disclose or otherwise use this
> message. If you have received this email in error, please delete it, and
> advise the sender immediately. *
>
>
>
> --
> ___
> 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] [PATCH 2/2] Kill suprocesses when pressing ctrl+c

2014-08-21 Thread Paul Eggleton

Hi Marius,

On Thursday 21 August 2014 15:00:31 Marius Avram wrote:
> This way the created bitbake subprocesses from the upgrade script
> are killed as well when you press ctrl+c.
> 
> Signed-off-by: Marius Avram 
> ---
>  upgradehelper.py |6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/upgradehelper.py b/upgradehelper.py
> index 771c981..7db89a7 100755
> --- a/upgradehelper.py
> +++ b/upgradehelper.py
> @@ -35,6 +35,7 @@ from logging import warning as W
>  from logging import error as E
>  from logging import critical as C
>  import re
> +import signal
>  import sys
>  import ConfigParser as cp
>  from datetime import datetime
> @@ -645,11 +646,16 @@ class UniverseUpdater(Updater):
>  self.prepare()
>  super(UniverseUpdater, self).run()
> 
> +def close_child_processes(signal_id, frame):
> +pid = os.getpid()
> +os.killpg(pid, signal.SIGKILL)

I could be wrong but I think this ought to be:

pgid = os.getpgrp()
os.killpg(pgid, signal.SIGKILL)

> 
>  if __name__ == "__main__":
>  global settings
>  global maintainer_override
> 
> +signal.signal(signal.SIGINT, close_child_processes)
> +
>  debug_levels = [log.CRITICAL, log.ERROR, log.WARNING, log.INFO,
> log.DEBUG] args = parse_cmdline()
>  log.basicConfig(format='%(levelname)s:%(message)s',

-- 

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

Re: [yocto] [PATCH 1/2] Send emails for a list of recipes

2014-08-21 Thread Paul Eggleton

Hi Marius,

On Thursday 21 August 2014 15:00:30 Marius Avram wrote:
> If the --emails or -e command line argument is active and a single
> or a list of recipes are given to the script, emails with the results
> and patches will be sent to their maintainers or to the overriden
> addresses from the configuration file.
> 
> Also the status email will be sent in the case a selection of
> at least two recipes has been given to the script for upgrading.
> 
> Signed-off-by: Marius Avram 
> ---
>  upgradehelper.py |  199
> +++--- 1 file changed, 98
> insertions(+), 101 deletions(-)
> 
> diff --git a/upgradehelper.py b/upgradehelper.py
> index cc90958..771c981 100755
> --- a/upgradehelper.py
> +++ b/upgradehelper.py
> @@ -71,6 +71,8 @@ def parse_cmdline():
>  help="disable interactive mode")
>  parser.add_argument("-d", "--debug-level", type=int, default=4,
> choices=range(1, 6), help="set the debug level: CRITICAL=1, ERROR=2,
> WARNING=3, INFO=4, DEBUG=5") 
> +parser.add_argument("-e", "--emails", type=bool, default=False, 
> +help="send emails to recipe maintainers") 

Picky I know, but could you make the long option --send-emails?

> @@ -125,10 +147,10 @@ class Updater(object):
>  self.bb = Bitbake(get_build_dir())
>  self.buildhistory = BuildHistory(get_build_dir())
>  self.git = None
> -
> -self.author = None
> +self.author = "Upgrade Helper "

Does this mean that the author value is now forced to be this even if
I just want to upgrade a few recipes locally with the tool (and therefore
my own author info should be used)?

> -if self.statistics.total_attempted:
> -self.send_email(to_list, subject, msg)
> -else:
> -W("No recipes attempted, not sending status mail!")
> +super(UniverUpdate, self).pkg_upgrade_handler(self)

Shouldn't this be UniverseUpdater?

Cheers,
Paul

-- 

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

[yocto] [PATCH 2/2] Kill suprocesses when pressing ctrl+c

2014-08-21 Thread Marius Avram

This way the created bitbake subprocesses from the upgrade script
are killed as well when you press ctrl+c.

Signed-off-by: Marius Avram 
---
 upgradehelper.py |6 ++
 1 file changed, 6 insertions(+)

diff --git a/upgradehelper.py b/upgradehelper.py
index 9ddfcb5..4ee65d5 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -35,6 +35,7 @@ from logging import warning as W
 from logging import error as E
 from logging import critical as C
 import re
+import signal
 import sys
 import ConfigParser as cp
 from datetime import datetime
@@ -645,11 +646,16 @@ class UniverseUpdater(Updater):
 self.prepare()
 super(UniverseUpdater, self).run()
 
+def close_child_processes(signal_id, frame):
+pid = os.getpgrp()
+os.killpg(pid, signal.SIGKILL)
 
 if __name__ == "__main__":
 global settings
 global maintainer_override
 
+signal.signal(signal.SIGINT, close_child_processes)
+
 debug_levels = [log.CRITICAL, log.ERROR, log.WARNING, log.INFO, log.DEBUG]
 args = parse_cmdline()
 log.basicConfig(format='%(levelname)s:%(message)s',
-- 
1.7.9.5

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

[yocto] [auh][PATCH v2 1/2] Send emails for a list of recipes

2014-08-21 Thread Marius Avram

If the --emails or -e command line argument is active and a single
or a list of recipes are given to the script, emails with the results
and patches will be sent to their maintainers or to the overriden
addresses from the configuration file.

Also the status email will be sent in the case a selection of
at least two recipes has been given to the script for upgrading.

Signed-off-by: Marius Avram 
---
 upgradehelper.py |  199 +++---
 1 file changed, 98 insertions(+), 101 deletions(-)

diff --git a/upgradehelper.py b/upgradehelper.py
index cc90958..9ddfcb5 100755
--- a/upgradehelper.py
+++ b/upgradehelper.py
@@ -71,6 +71,8 @@ def parse_cmdline():
 help="disable interactive mode")
 parser.add_argument("-d", "--debug-level", type=int, default=4, 
choices=range(1, 6),
 help="set the debug level: CRITICAL=1, ERROR=2, 
WARNING=3, INFO=4, DEBUG=5")
+parser.add_argument("-e", "--emails", type=bool, default=False,
+help="send emails to recipe maintainers")
 parser.add_argument("-s", "--skip-compilation", action="store_true", 
default=False,
 help="do not compile, just change the checksums, 
remove PR, and commit")
 parser.add_argument("-c", "--config-file", default=None,
@@ -116,7 +118,27 @@ def parse_config_file(config_file):
 return (settings, maintainer_override)
 
 class Updater(object):
-def __init__(self, auto_mode=False, skip_compilation=False):
+mail_header = \
+"Hello,\n\nYou are receiving this email because you are the 
maintainer\n" \
+"of *%s* recipe and this is to let you know that the automatic 
attempt\n" \
+"to upgrade the recipe to *%s* has %s.\n\n"
+
+next_steps_info = \
+"The recipe has been successfully compiled for all major 
architectures.\n\n" \
+"Next steps:\n" \
+"- apply the patch: git am %s\n" \
+"- check that required patches have not been removed from the 
recipe\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" \
+
+mail_footer = \
+"Attached are the patch and the logs (+ license file diff) in case of 
failure.\n\n" \
+"Regards,\nThe Upgrade Helper"
+
+
+def __init__(self, auto_mode=False, send_email=False, 
skip_compilation=False):
 
 self.uh_dir = get_build_dir() + "/upgrade-helper"
 if not os.path.exists(self.uh_dir):
@@ -125,10 +147,10 @@ class Updater(object):
 self.bb = Bitbake(get_build_dir())
 self.buildhistory = BuildHistory(get_build_dir())
 self.git = None
-
-self.author = None
+self.author = "Upgrade Helper "
 self.skip_compilation = skip_compilation
 self.interactive = not auto_mode
+self.send_email = send_email
 
 self.machines = ["qemux86", "qemux86-64", "qemuarm", "qemumips", 
"qemuppc"]
 
@@ -144,6 +166,7 @@ class Updater(object):
 (self._compile, None)
 ]
 
+self.email_handler = Email(settings)
 self.statistics = Statistics()
 
 
@@ -307,8 +330,9 @@ class Updater(object):
 
 # this function will be called at the end of each recipe upgrade
 def pkg_upgrade_handler(self, err):
-if err is not None and self.patch_file is not None:
+if err and self.patch_file:
 answer = "N"
+status_msg = str(err)
 if self.interactive:
 I(" %s: Do you want to keep the changes? (y/N)" % self.pn)
 answer = sys.stdin.readline().strip().upper()
@@ -317,6 +341,53 @@ class Updater(object):
 I(" %s: Dropping changes from git ..." % self.pn)
 self.git.reset_hard(1)
 self.git.clean_untracked()
+return
+elif not err:
+status_msg = "Succeeded"
+
+status = type(err).__name__
+
+# drop last upgrade from git. It's safer this way if the upgrade has
+# problems and other recipes depend on it. Give the other recipes a
+# chance...
+if ("drop_previous_commits" in settings and
+settings["drop_previous_commits"] == "yes" and
+err) or (err and self.patch_file):
+I(" %s: Dropping changes from git ..." % self.pn)
+self.git.reset_hard(1)
+self.git.clean_untracked()
+
+if self.send_email:
+# don't bother maintainer with mail if the recipe is already up to 
date
+if status == "UpgradeNotNeededError":
+return
+
+if self.maintainer in maintainer_override:
+to_addr = maintainer_override[self.maintainer]
+else:
+to_addr = self.maintainer
+
+subjec

[yocto] [meta-oracle-java][PATCH] update jdk and jre to version 67

2014-08-21 Thread Vladimir Redzhepov

>From f0305398a51435f407e41a8f0eaf83f8bdd13cca Mon Sep 17 00:00:00 2001
From: Vladimir Redzhepov 
Date: Thu, 21 Aug 2014 19:43:29 +0300
Subject: [PATCH] update jdk and jre to version 67

Signed-off-by: Vladimir Redzhepov 
---
recipes-devtools/oracle-java/oracle-jse-jdk-i586_1.7.0.bb   | 10 +-
recipes-devtools/oracle-java/oracle-jse-jdk-x86-64_1.7.0.bb | 10 +-
recipes-devtools/oracle-java/oracle-jse-jre-i586_1.7.0.bb   | 10 +-
recipes-devtools/oracle-java/oracle-jse-jre-x86-64_1.7.0.bb | 10 +-
recipes-devtools/oracle-java/oracle-jse.inc |  4 ++--
5 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/recipes-devtools/oracle-java/oracle-jse-jdk-i586_1.7.0.bb 
b/recipes-devtools/oracle-java/oracle-jse-jdk-i586_1.7.0.bb
index 978fbd5..07fa39b 100644
--- a/recipes-devtools/oracle-java/oracle-jse-jdk-i586_1.7.0.bb
+++ b/recipes-devtools/oracle-java/oracle-jse-jdk-i586_1.7.0.bb
@@ -1,9 +1,9 @@
-PR = "r0"
-PV_UPDATE = "25"
+PR = "r1"
+PV_UPDATE = "67"
 require oracle-jse-jdk.inc
-SRC_URI = 
"http://download.oracle.com/otn-pub/java/jdk/7u25-b15/jdk-7u25-linux-i586.tar.gz";
+SRC_URI = 
"http://download.oracle.com/otn-pub/java/jdk/7u67-b01/jdk-7u67-linux-i586.tar.gz";
-SRC_URI[md5sum] = "23176d0ebf9dedd21e3150b4bb0ee776"
-SRC_URI[sha256sum] = 
"dd89b20afa939992bb7fdc44837fa64f0a98d7ee1e5706fe8a2d9e2247ba6de7"
+SRC_URI[md5sum] = "715b0e8ba2a06bded75f6a92427e2701"
+SRC_URI[sha256sum] = 
"b6231064ad2c9fbbcb099dba17b1dcf12033e922b9c24e4348b9a01e9ebaa85c"
diff --git a/recipes-devtools/oracle-java/oracle-jse-jdk-x86-64_1.7.0.bb 
b/recipes-devtools/oracle-java/oracle-jse-jdk-x86-64_1.7.0.bb
index 7979401..8bad119 100644
--- a/recipes-devtools/oracle-java/oracle-jse-jdk-x86-64_1.7.0.bb
+++ b/recipes-devtools/oracle-java/oracle-jse-jdk-x86-64_1.7.0.bb
@@ -1,9 +1,9 @@
-PR = "r0"
-PV_UPDATE = "25"
+PR = "r1"
+PV_UPDATE = "67"
 require oracle-jse-jdk.inc
-SRC_URI = 
"http://download.oracle.com/otn-pub/java/jdk/7u25-b15/jdk-7u25-linux-x64.tar.gz";
+SRC_URI = 
"http://download.oracle.com/otn-pub/java/jdk/7u67-b01/jdk-7u67-linux-x64.tar.gz";
-SRC_URI[md5sum] = "83ba05e260813f7a9140b76e3d37ea33"
-SRC_URI[sha256sum] = 
"f80dff0e19ca8d038cf7fe3aaa89538496b80950f4d10ff5f457988ae159b2a6"
+SRC_URI[md5sum] = "81e3e2df33e13781e5fac5756ed90e67"
+SRC_URI[sha256sum] = 
"54dd1e13edf18c64941a55da9c91210b53dc5cf48f1a8f4538c863049e346335"
diff --git a/recipes-devtools/oracle-java/oracle-jse-jre-i586_1.7.0.bb 
b/recipes-devtools/oracle-java/oracle-jse-jre-i586_1.7.0.bb
index 6125025..4165d74 100644
--- a/recipes-devtools/oracle-java/oracle-jse-jre-i586_1.7.0.bb
+++ b/recipes-devtools/oracle-java/oracle-jse-jre-i586_1.7.0.bb
@@ -1,9 +1,9 @@
-PR = "r0"
-PV_UPDATE = "25"
+PR = "r1"
+PV_UPDATE = "67"
 require oracle-jse-jre.inc
-SRC_URI = 
"http://download.oracle.com/otn-pub/java/jdk/7u25-b15/jre-7u25-linux-i586.tar.gz";
+SRC_URI = 
"http://download.oracle.com/otn-pub/java/jdk/7u67-b01/jre-7u67-linux-i586.tar.gz";
-SRC_URI[md5sum] = "0e9ccefe49e937e592dbb605f2e8e7d8"
-SRC_URI[sha256sum] = 
"4016965536d8607743267812ab04e6d428036dda432893748c1df6cb77b09628"
+SRC_URI[md5sum] = "2a256eb2a91f0084e58c612636342c2b"
+SRC_URI[sha256sum] = 
"eadec83a54d3a9d09248a8d16b21c03da9afffc7317e775fb8db962620a0781d"
diff --git a/recipes-devtools/oracle-java/oracle-jse-jre-x86-64_1.7.0.bb 
b/recipes-devtools/oracle-java/oracle-jse-jre-x86-64_1.7.0.bb
index 4058d23..a1474a9 100644
--- a/recipes-devtools/oracle-java/oracle-jse-jre-x86-64_1.7.0.bb
+++ b/recipes-devtools/oracle-java/oracle-jse-jre-x86-64_1.7.0.bb
@@ -1,9 +1,9 @@
-PR = "r0"
-PV_UPDATE = "25"
+PR = "r1"
+PV_UPDATE = "67"
 require oracle-jse-jre.inc
-SRC_URI = 
"http://download.oracle.com/otn-pub/java/jdk/7u25-b15/jre-7u25-linux-x64.tar.gz";
+SRC_URI = 
"http://download.oracle.com/otn-pub/java/jdk/7u67-b01/jre-7u67-linux-x64.tar.gz";
-SRC_URI[md5sum] = "743ee0ebf73ce428c912866d84e374e0"
-SRC_URI[sha256sum] = 
"3c4496316fb413d5ab0590e9971676a521b9a600b3ceaac311f04c18c98a98c0"
+SRC_URI[md5sum] = "9007c79167be0177fb47e5313c53d5cb"
+SRC_URI[sha256sum] = 
"726c37c07bb389b5b96674b7bcbc288e39fb8fbcd42369afa364a18e66248b1f"
diff --git a/recipes-devtools/oracle-java/oracle-jse.inc 
b/recipes-devtools/oracle-java/oracle-jse.inc
index 3a4e20d..38ceef0 100644
--- a/recipes-devtools/oracle-java/oracle-jse.inc
+++ b/recipes-devtools/oracle-java/oracle-jse.inc
@@ -2,8 +2,8 @@ LICENSE_FLAGS = "oracle_java"
LICENSE = "Oracle_Binary_Code_License_Agreement"
LIC_FILES_CHKSUM = "\
   
file://${WORKDIR}/${JDK_JRE}${PV}_${PV_UPDATE}/LICENSE;md5=98f46ab6481d87c4d77e0e91a6dbc15f
 \
-  
file://${WORKDIR}/${JDK_JRE}${PV}_${PV_UPDATE}/COPYRIGHT;md5=3a11238025bf13b87f04753183ffeb90
 \
-
file://${WORKDIR}/${JDK_JRE}${PV}_${PV_UPDATE}/THIRDPARTYLICENSEREADME.txt;md5=c339b34e3da6673d2c5950d0f8808f8c
 \
+ 
file://${WORKDIR}/${JDK_JRE}${PV}_${PV_UPDATE}/COPYRIGHT;md5=be9fe5d47a7dcfb78f142f487afb34bb
 \
+
file://${WORKDIR}

Re: [yocto] [meta-oracle-java][PATCH] update jdk and jre to version 67

2014-08-21 Thread Martin Jansa

On Thu, Aug 21, 2014 at 05:01:47PM +, Vladimir Redzhepov wrote:
> From f0305398a51435f407e41a8f0eaf83f8bdd13cca Mon Sep 17 00:00:00 2001
> From: Vladimir Redzhepov 
> Date: Thu, 21 Aug 2014 19:43:29 +0300
> Subject: [PATCH] update jdk and jre to version 67
> 
> Signed-off-by: Vladimir Redzhepov 
> ---
> recipes-devtools/oracle-java/oracle-jse-jdk-i586_1.7.0.bb   | 10 +-
> recipes-devtools/oracle-java/oracle-jse-jdk-x86-64_1.7.0.bb | 10 +-
> recipes-devtools/oracle-java/oracle-jse-jre-i586_1.7.0.bb   | 10 +-
> recipes-devtools/oracle-java/oracle-jse-jre-x86-64_1.7.0.bb | 10 +-
> recipes-devtools/oracle-java/oracle-jse.inc |  4 ++--
> 5 files changed, 22 insertions(+), 22 deletions(-)
> 
> diff --git a/recipes-devtools/oracle-java/oracle-jse-jdk-i586_1.7.0.bb 
> b/recipes-devtools/oracle-java/oracle-jse-jdk-i586_1.7.0.bb
> index 978fbd5..07fa39b 100644
> --- a/recipes-devtools/oracle-java/oracle-jse-jdk-i586_1.7.0.bb
> +++ b/recipes-devtools/oracle-java/oracle-jse-jdk-i586_1.7.0.bb
> @@ -1,9 +1,9 @@
> -PR = "r0"
> -PV_UPDATE = "25"
> +PR = "r1"
> +PV_UPDATE = "67"

Does it need PR update?

>  require oracle-jse-jdk.inc
> -SRC_URI = 
> "http://download.oracle.com/otn-pub/java/jdk/7u25-b15/jdk-7u25-linux-i586.tar.gz";
> +SRC_URI = 
> "http://download.oracle.com/otn-pub/java/jdk/7u67-b01/jdk-7u67-linux-i586.tar.gz";

It would be better to use PV_UPDATE variable here and maybe introduce
another one for build number?

> -SRC_URI[md5sum] = "23176d0ebf9dedd21e3150b4bb0ee776"
> -SRC_URI[sha256sum] = 
> "dd89b20afa939992bb7fdc44837fa64f0a98d7ee1e5706fe8a2d9e2247ba6de7"
> +SRC_URI[md5sum] = "715b0e8ba2a06bded75f6a92427e2701"
> +SRC_URI[sha256sum] = 
> "b6231064ad2c9fbbcb099dba17b1dcf12033e922b9c24e4348b9a01e9ebaa85c"
> diff --git a/recipes-devtools/oracle-java/oracle-jse-jdk-x86-64_1.7.0.bb 
> b/recipes-devtools/oracle-java/oracle-jse-jdk-x86-64_1.7.0.bb
> index 7979401..8bad119 100644
> --- a/recipes-devtools/oracle-java/oracle-jse-jdk-x86-64_1.7.0.bb
> +++ b/recipes-devtools/oracle-java/oracle-jse-jdk-x86-64_1.7.0.bb
> @@ -1,9 +1,9 @@
> -PR = "r0"
> -PV_UPDATE = "25"
> +PR = "r1"
> +PV_UPDATE = "67"
>  require oracle-jse-jdk.inc
> -SRC_URI = 
> "http://download.oracle.com/otn-pub/java/jdk/7u25-b15/jdk-7u25-linux-x64.tar.gz";
> +SRC_URI = 
> "http://download.oracle.com/otn-pub/java/jdk/7u67-b01/jdk-7u67-linux-x64.tar.gz";
> -SRC_URI[md5sum] = "83ba05e260813f7a9140b76e3d37ea33"
> -SRC_URI[sha256sum] = 
> "f80dff0e19ca8d038cf7fe3aaa89538496b80950f4d10ff5f457988ae159b2a6"
> +SRC_URI[md5sum] = "81e3e2df33e13781e5fac5756ed90e67"
> +SRC_URI[sha256sum] = 
> "54dd1e13edf18c64941a55da9c91210b53dc5cf48f1a8f4538c863049e346335"
> diff --git a/recipes-devtools/oracle-java/oracle-jse-jre-i586_1.7.0.bb 
> b/recipes-devtools/oracle-java/oracle-jse-jre-i586_1.7.0.bb
> index 6125025..4165d74 100644
> --- a/recipes-devtools/oracle-java/oracle-jse-jre-i586_1.7.0.bb
> +++ b/recipes-devtools/oracle-java/oracle-jse-jre-i586_1.7.0.bb
> @@ -1,9 +1,9 @@
> -PR = "r0"
> -PV_UPDATE = "25"
> +PR = "r1"
> +PV_UPDATE = "67"
>  require oracle-jse-jre.inc
> -SRC_URI = 
> "http://download.oracle.com/otn-pub/java/jdk/7u25-b15/jre-7u25-linux-i586.tar.gz";
> +SRC_URI = 
> "http://download.oracle.com/otn-pub/java/jdk/7u67-b01/jre-7u67-linux-i586.tar.gz";
> -SRC_URI[md5sum] = "0e9ccefe49e937e592dbb605f2e8e7d8"
> -SRC_URI[sha256sum] = 
> "4016965536d8607743267812ab04e6d428036dda432893748c1df6cb77b09628"
> +SRC_URI[md5sum] = "2a256eb2a91f0084e58c612636342c2b"
> +SRC_URI[sha256sum] = 
> "eadec83a54d3a9d09248a8d16b21c03da9afffc7317e775fb8db962620a0781d"
> diff --git a/recipes-devtools/oracle-java/oracle-jse-jre-x86-64_1.7.0.bb 
> b/recipes-devtools/oracle-java/oracle-jse-jre-x86-64_1.7.0.bb
> index 4058d23..a1474a9 100644
> --- a/recipes-devtools/oracle-java/oracle-jse-jre-x86-64_1.7.0.bb
> +++ b/recipes-devtools/oracle-java/oracle-jse-jre-x86-64_1.7.0.bb
> @@ -1,9 +1,9 @@
> -PR = "r0"
> -PV_UPDATE = "25"
> +PR = "r1"
> +PV_UPDATE = "67"
>  require oracle-jse-jre.inc
> -SRC_URI = 
> "http://download.oracle.com/otn-pub/java/jdk/7u25-b15/jre-7u25-linux-x64.tar.gz";
> +SRC_URI = 
> "http://download.oracle.com/otn-pub/java/jdk/7u67-b01/jre-7u67-linux-x64.tar.gz";
> -SRC_URI[md5sum] = "743ee0ebf73ce428c912866d84e374e0"
> -SRC_URI[sha256sum] = 
> "3c4496316fb413d5ab0590e9971676a521b9a600b3ceaac311f04c18c98a98c0"
> +SRC_URI[md5sum] = "9007c79167be0177fb47e5313c53d5cb"
> +SRC_URI[sha256sum] = 
> "726c37c07bb389b5b96674b7bcbc288e39fb8fbcd42369afa364a18e66248b1f"
> diff --git a/recipes-devtools/oracle-java/oracle-jse.inc 
> b/recipes-devtools/oracle-java/oracle-jse.inc
> index 3a4e20d..38ceef0 100644
> --- a/recipes-devtools/oracle-java/oracle-jse.inc
> +++ b/recipes-devtools/oracle-java/oracle-jse.inc
> @@ -2,8 +2,8 @@ LICENSE_FLAGS = "oracle_java"
> LICENSE = "Oracle_Binary_Code_License_Agreement"
> LIC_FILES_CHKSUM = "\
>
> file://${WORKDIR}/${JDK_JRE}${PV}_${PV_UPDATE}/LICENSE;md5=98f46ab6481d87c4d7

Re: [yocto] Kernel driver for Turbosight TBS6285 DVB card

2014-08-21 Thread Bruce Ashfield

On 14-08-21 04:17 AM, Chris Tapp wrote:

On 21 Aug 2014, at 05:08, Bruce Ashfield wrote:

On Wed, Aug 20, 2014 at 4:11 PM, Chris Tapp wrote:

Hi Bruce,

Thanks for the feedback.

On 20 Aug 2014, at 03:08, Bruce Ashfield wrote:

On 2014-08-19, 5:26 PM, Chris Tapp wrote:

I need to include the kernel driver for the Turbosight TBS6285 DVB card in an
image.

The official bundle at
http://www.tbsdtv.com/download/document/common/tbs-linux-drivers_v140707.zip includes the
drivers and a load of other "stuff" (e.g. a full V4L build).

LinuxTV.org have the drivers extracted into a .tar.bz2 at (e.g.)
http://linuxtv.org/downloads/drivers/linux-media-LATEST.tar.bz2, so I plan to
use this as the download source.

This bit is wrong - I need to use the .tar.bz within the .zip.

So far I have a recipe which downloads from this URL and extracts the files
into the work area and ${WORKAREA}/drivers/media includes a Makefile and
Kconfig.

I've looked at the Yocto documentation, but this doesn't seem to be a good match for the
"Out of tree" kernel module case.

Hmm. At a glance, I'd say that it does sound like a typical out of
tree module build.

Ah, ok - to my (untrained) eye the use-case looked completely different based
on the example.

Did you try adopting the meta-skeleton hello-mod recipe and point it
at that source directory ?

I have now (with the above change). However, it looks as if something within
the build is referencing the host file system when building.

I'm building for ValleyIsland 32-bit:

1) If I configure the drivers for 32-bit there is a linker error complaining
that elf 32 and elf 64 aren't compatible (host is 64 bit);

Hmm. The target arch should be used for this build. Are you enabling a
multi lib config
as well ?

Not that I know of ;-)

The build uses a .version file to specify the kernel. The top makefile creates this using 'uname
-r' by default. I can run 'make dir DIR="..." in do_configure() to specify the path to
the yocto kernel files, which seems to fix this (after modifying another makefile, which prepends
"../" to the DIR path).

Definite host contamination there. You likely want the code, but
not the build infrastructure in this case.

2) Everything appears to build if I target 64-bit, but the installer tries to
modify /lib/modules/3.2.0-67/..., which is also part of the host.

Do the Makefile's that come in that archive (I haven't gone to look)
have a custom
install rule ? If so, that's likely the problem. If the kernel's build
system is triggered
(i.e. the makefile follows the conventions), everything will be
installed to the proper
location.

The installer uses DESTDIR to select the installation path - I've not worked
out how this gets set yet or how I can set it from within my recipe.

Is there a trick I can use to get the kernel's build system to manage things?

In this case, you really need to replace (or patch) the existing Makefile
that comes with the package.

The hello-mod example I pointed out has makefile that shows the right
definitions to allow the kernel's build system to enter the directory, build
and install the modules.

Bruce

Looks like I need a patch ;-) Any pointers to where I should be looking would
be appreciated as this isn't my normal area...

Chris Tapp
opensou...@keylevel.com
www.keylevel.com

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

--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Chris Tapp
opensou...@keylevel.com
www.keylevel.com

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

Re: [yocto] Kernel driver for Turbosight TBS6285 DVB card

2014-08-21 Thread Chris Tapp


On 21 Aug 2014, at 19:28, Bruce Ashfield  wrote:

> On 14-08-21 04:17 AM, Chris Tapp wrote:
>> On 21 Aug 2014, at 05:08, Bruce Ashfield  wrote:
>> 
>>> On Wed, Aug 20, 2014 at 4:11 PM, Chris Tapp  wrote:
 Hi Bruce,
 
 Thanks for the feedback.
 
 On 20 Aug 2014, at 03:08, Bruce Ashfield  
 wrote:
 
> On 2014-08-19, 5:26 PM, Chris Tapp wrote:
>> I need to include the kernel driver for the Turbosight TBS6285 DVB card 
>> in an image.
>> 
>> The official bundle at 
>> http://www.tbsdtv.com/download/document/common/tbs-linux-drivers_v140707.zip
>>  includes the drivers and a load of other "stuff" (e.g. a full V4L 
>> build).
>> 
>> LinuxTV.org have the drivers extracted into a .tar.bz2 at (e.g.) 
>> http://linuxtv.org/downloads/drivers/linux-media-LATEST.tar.bz2, so I 
>> plan to use this as the download source.
 This bit is wrong - I need to use the .tar.bz within the .zip.
 
>> So far I have a recipe which downloads from this URL and extracts the 
>> files into the work area and ${WORKAREA}/drivers/media includes a 
>> Makefile and Kconfig.
>> 
>> I've looked at the Yocto documentation, but this doesn't seem to be a 
>> good match for the "Out of tree" kernel module case.
> Hmm. At a glance, I'd say that it does sound like a typical out of
> tree module build.
 Ah, ok - to my (untrained) eye the use-case looked completely different 
 based on the example.
 
> Did you try adopting the meta-skeleton hello-mod recipe and point it
> at that source directory ?
 I have now (with the above change). However, it looks as if something 
 within the build is referencing the host file system when building.
 
 I'm building for ValleyIsland 32-bit:
 
  1) If I configure the drivers for 32-bit there is a linker error 
 complaining that elf 32 and elf 64 aren't compatible (host is 64 bit);
>>> Hmm. The target arch should be used for this build. Are you enabling a
>>> multi lib config
>>> as well ?
>> Not that I know of ;-)
>> 
>> The build uses a .version file to specify the kernel. The top makefile 
>> creates this using 'uname -r' by default. I can run 'make dir DIR="..." in 
>> do_configure() to specify the path to the yocto kernel files, which seems to 
>> fix this (after modifying another makefile, which prepends "../" to the DIR 
>> path).
> 
> Definite host contamination there. You likely want the code, but
> not the build infrastructure in this case.
> 
>> 
>>>  2) Everything appears to build if I target 64-bit, but the installer tries 
>>> to modify /lib/modules/3.2.0-67/..., which is also part of the host.
>>> 
>>> Do the Makefile's that come in that archive (I haven't gone to look)
>>> have a custom
>>> install rule ? If so, that's likely the problem. If the kernel's build
>>> system is triggered
>>> (i.e. the makefile follows the conventions), everything will be
>>> installed to the proper
>>> location.
>> The installer uses DESTDIR to select the installation path - I've not worked 
>> out how this gets set yet or how I can set it from within my recipe.
>> 
>> Is there a trick I can use to get the kernel's build system to manage things?
> 
> In this case, you really need to replace (or patch) the existing Makefile
> that comes with the package.
> 
> The hello-mod example I pointed out has makefile that shows the right
> definitions to allow the kernel's build system to enter the directory, build
> and install the modules.

I've made some good progress, but still not quite there.

I've got a do_compile() that basically does:

  make DIR=${STAGING_KERNEL_DIR}

The appears to build the modules correctly - testing will tell ;-)

I've then got similar in do_install():

  make DIR=${STAGING_KERNEL_DIR} DESTDIR=${D}

That's 99% there - the modules get put in image/lib/modules/3.10.40-ltsi/...
They should be in image/lib/modules/3.10.40-ltsi-yocto-standard/... - not sure 
yet how to fix this one.

There is also a packaging QA issue causing a build failure (some files aren't 
used), but an INSANE_SKIP installed-vs-shipped fixes that one for now.

--

Chris Tapp
opensou...@keylevel.com
www.keylevel.com




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

Re: [yocto] [meta-oracle-java][PATCH] update jdk and jre to version 67

2014-08-21 Thread Maxin B. John

Hi Vladimir,

On Thu, Aug 21, 2014 at 05:01:47PM +, Vladimir Redzhepov wrote:
> From f0305398a51435f407e41a8f0eaf83f8bdd13cca Mon Sep 17 00:00:00 2001
> 
> From: Vladimir Redzhepov 
> 
> Date: Thu, 21 Aug 2014 19:43:29 +0300
> 
> Subject: [PATCH] update jdk and jre to version 67
> 
>  
> 
> Signed-off-by: Vladimir Redzhepov 
> 
> ---
> recipes-devtools/oracle-java/oracle-jse-jdk-i586_1.7.0.bb   | 10 +-

In addition to Martin's review comments, patch doesn't seems to apply properly:

Applying: update jdk and jre to version 67
fatal: corrupt patch at line 27
Patch failed at 0001 update jdk and jre to version 67

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

Re: [yocto] Kernel driver for Turbosight TBS6285 DVB card

2014-08-21 Thread Bruce Ashfield

On 14-08-21 03:11 PM, Chris Tapp wrote:

On 21 Aug 2014, at 19:28, Bruce Ashfield wrote: