Re: [yocto] Cleanly moving files from one package to another

2015-12-10 Thread Bryan Evenson 
Martin,

> -Original Message-
> From: Martin Jansa [mailto:martin.ja...@gmail.com]
> Sent: Thursday, December 10, 2015 12:03 PM
> To: Bryan Evenson 
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Cleanly moving files from one package to another
> 
> On Thu, Dec 10, 2015 at 04:20:45PM +, Bryan Evenson wrote:
> > Martin,
> >
> > > -Original Message-
> > > From: Martin Jansa [mailto:martin.ja...@gmail.com]
> > > Sent: Thursday, December 10, 2015 9:39 AM
> > > To: Bryan Evenson 
> > > Cc: yocto@yoctoproject.org
> > > Subject: Re: [yocto] Cleanly moving files from one package to another
> > >
> > > On Thu, Dec 10, 2015 at 02:15:05PM +, Bryan Evenson wrote:
> > > > Martin,
> > > >
> > > > > -Original Message-
> > > > > From: Martin Jansa [mailto:martin.ja...@gmail.com]
> > > > > Sent: Thursday, December 10, 2015 4:20 AM
> > > > > To: Bryan Evenson 
> > > > > Cc: yocto@yoctoproject.org
> > > > > Subject: Re: [yocto] Cleanly moving files from one package to
> > > > > another
> > > > >
> > > > > On Wed, Dec 09, 2015 at 08:19:40PM +, Bryan Evenson wrote:
> > > > > > All,
> > > > > >
> > > > > > I'm on poky/dizzy-1.7.3 and I'm using opkg for a package manager.
> > > > > > I have a
> > > > > few script files that are part of one package that really belong with
> > > another.
> > > > > So I updated both recipes, removed the file from one recipe and
> > > > > added it to the other recipe.  I built everything, made the opkg
> > > > > feed repo and tried to upgrade with "opkg update; opkg upgrade" to
> > > > > see how clean the upgrade was.  For each script file I moved from
> > > > > one package to the other I get an error message of the form:
> > > > > >
> > > > > > * check_data_file_clashes: Package A wants to install file
> > > > > /path/to/script/file
> > > > > > But that file is already provided by package  * B
> > > > > >
> > > > > > I know I can do "opkg upgrade --force-overwrite", but I'd like to
> > > > > > make
> > > > > recipe changes so that it upgrades cleanly.  All I've done in the
> > > > > recipes is remove the script files from the FILES variable and the
> > > > > do_install step of one recipe and added the script to the FILES
> > > > > variable and do_install step of the other recipe.  I know
> > > > > update-alternatives can be used if more than one package provides
> > > > > the same binary, but is that necessary in this case when
> > > > > transferring ownership to another package?  Is there anything else I
> can
> > > do in the recipes to prevent the opkg install errors?
> > > > >
> > > > > Have you tried to set
> > > > > RREPLACES_ = ""
> > > > > ?
> > > >
> > > > I haven't tried that because I'm not replacing a package.  Both packages
> still
> > > exist on the system and are both needed, it's just that ownership of one
> of
> > > the files is being transferred from one package to another.  Would I still
> use
> > > RREPLACES even if I want to keep both packages on the system?
> > > >
> > > > Specifically in this case, I have some script files for scheduled tasks 
> > > > that
> > > were part of one of my self-made packages.  However, they really belong
> > > with cronie since this is what is calling the scripts.  So I removed the 
> > > script
> files
> > > from my self-made package and added them to cronie.  My package has
> > > other files still associated with it (that do belong with it) installed 
> > > on my
> > > system.  So I want to keep both packages on my system, but I just want
> to
> > > change ownership of these script files from my package to cronie.  Is
> > > RREPLACES the tool for this job?
> > >
> > > > Is RREPLACES the tool for this job?
> > >
> > > Yes, see
> > > https://www.debian.org/doc/debian-policy/ch-relationships.html#s-
> > > replaces
> > >
> > > opkg should work the same.
> >
> > Now I'm having something happen that I haven't seen before with the PR
> service.  I updated my .bbappend to add the RREPLACES as you suggested,
> but bitbake didn't rebuild the package.  I tried doing bitbake -c clean and
> bitbake -c cleansstate and both times the built package had the same full
> version number as it did before I made the RREPLACES change.  I opened the
> ipk with Archive Manager and looked at DEBIAN/control, and there was no
> "Depends: " line in the control file.  Then I noticed that this .bbappend had
> "inherit pkgconfig" and it isn't needed in the .bbappend.  So while I was at 
> it I
> deleted the line "inherit pkgconfig" and tried to build the package again
> (without issuing a bitbake -c clean first).  This time it built the package 
> and the
> PR service incremented the version.  I opened the resulting ipk and looked at
> DEBIAN/control again, and this time there was a "Depends:" line in the
> control file.
> >
> > Is changing RREPLACES not being seen as a metadata change by bitbake?  Is
> this a bug or is there something else I'm missing?
>

Re: [yocto] Cleanly moving files from one package to another

2015-12-10 Thread Martin Jansa 
On Thu, Dec 10, 2015 at 04:20:45PM +, Bryan Evenson wrote:
> Martin,
> 
> > -Original Message-
> > From: Martin Jansa [mailto:martin.ja...@gmail.com]
> > Sent: Thursday, December 10, 2015 9:39 AM
> > To: Bryan Evenson 
> > Cc: yocto@yoctoproject.org
> > Subject: Re: [yocto] Cleanly moving files from one package to another
> > 
> > On Thu, Dec 10, 2015 at 02:15:05PM +, Bryan Evenson wrote:
> > > Martin,
> > >
> > > > -Original Message-
> > > > From: Martin Jansa [mailto:martin.ja...@gmail.com]
> > > > Sent: Thursday, December 10, 2015 4:20 AM
> > > > To: Bryan Evenson 
> > > > Cc: yocto@yoctoproject.org
> > > > Subject: Re: [yocto] Cleanly moving files from one package to
> > > > another
> > > >
> > > > On Wed, Dec 09, 2015 at 08:19:40PM +, Bryan Evenson wrote:
> > > > > All,
> > > > >
> > > > > I'm on poky/dizzy-1.7.3 and I'm using opkg for a package manager.
> > > > > I have a
> > > > few script files that are part of one package that really belong with
> > another.
> > > > So I updated both recipes, removed the file from one recipe and
> > > > added it to the other recipe.  I built everything, made the opkg
> > > > feed repo and tried to upgrade with "opkg update; opkg upgrade" to
> > > > see how clean the upgrade was.  For each script file I moved from
> > > > one package to the other I get an error message of the form:
> > > > >
> > > > > * check_data_file_clashes: Package A wants to install file
> > > > /path/to/script/file
> > > > > But that file is already provided by package  * B
> > > > >
> > > > > I know I can do "opkg upgrade --force-overwrite", but I'd like to
> > > > > make
> > > > recipe changes so that it upgrades cleanly.  All I've done in the
> > > > recipes is remove the script files from the FILES variable and the
> > > > do_install step of one recipe and added the script to the FILES
> > > > variable and do_install step of the other recipe.  I know
> > > > update-alternatives can be used if more than one package provides
> > > > the same binary, but is that necessary in this case when
> > > > transferring ownership to another package?  Is there anything else I can
> > do in the recipes to prevent the opkg install errors?
> > > >
> > > > Have you tried to set
> > > > RREPLACES_ = ""
> > > > ?
> > >
> > > I haven't tried that because I'm not replacing a package.  Both packages 
> > > still
> > exist on the system and are both needed, it's just that ownership of one of
> > the files is being transferred from one package to another.  Would I still 
> > use
> > RREPLACES even if I want to keep both packages on the system?
> > >
> > > Specifically in this case, I have some script files for scheduled tasks 
> > > that
> > were part of one of my self-made packages.  However, they really belong
> > with cronie since this is what is calling the scripts.  So I removed the 
> > script files
> > from my self-made package and added them to cronie.  My package has
> > other files still associated with it (that do belong with it) installed on 
> > my
> > system.  So I want to keep both packages on my system, but I just want to
> > change ownership of these script files from my package to cronie.  Is
> > RREPLACES the tool for this job?
> > 
> > > Is RREPLACES the tool for this job?
> > 
> > Yes, see
> > https://www.debian.org/doc/debian-policy/ch-relationships.html#s-
> > replaces
> > 
> > opkg should work the same.
> 
> Now I'm having something happen that I haven't seen before with the PR 
> service.  I updated my .bbappend to add the RREPLACES as you suggested, but 
> bitbake didn't rebuild the package.  I tried doing bitbake -c clean and 
> bitbake -c cleansstate and both times the built package had the same full 
> version number as it did before I made the RREPLACES change.  I opened the 
> ipk with Archive Manager and looked at DEBIAN/control, and there was no 
> "Depends: " line in the control file.  Then I noticed that this .bbappend had 
> "inherit pkgconfig" and it isn't needed in the .bbappend.  So while I was at 
> it I deleted the line "inherit pkgconfig" and tried to build the package 
> again (without issuing a bitbake -c clean first).  This time it built the 
> package and the PR service incremented the version.  I opened the resulting 
> ipk and looked at DEBIAN/control again, and this time there was a "Depends:" 
> line in the control file.
> 
> Is changing RREPLACES not being seen as a metadata change by bitbake?  Is 
> this a bug or is there something else I'm missing?

It should invalidate sstate signature for do_package* task
(maybe just do_package_write_ipk), if it doesn't then it's a bug.

Best way to test this is to use bitbake -S package, before and after
such change and bitbake-diffsigs on generated .sigdata files to see if
it was noticed by bitbake.

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


signature.asc
Description: Digital signature
--

[yocto] Release Candidate Build for yocto-2.0_M1.rc1_M1.rc1 now available.

2015-12-10 Thread Poky Build User 
-e 
A release candidate build for yocto-2.0_M1.rc1 is now available at:

 
http://autobuilder.yoctoproject.org/pub/releases/yocto-2.0_M1.rc1


Please begin QA on this build as soon as possible.


Build hash information: 
meta-intel : 1ce13b3d39b2da79916e3a175cee6baa507290f1 
meta-fsl-arm : f544775ec71d69c6e81051a251b6b05395553397 
meta-minnow : 9c965ef5252e383843d796cd8b50c61b3034b6ae 
meta-qt4 : 17a4cd43438c22476b40d6dc79d4be6f4403708b 
meta-qt3 : 5233565c80db869f6f539f37f26ea6662d9dc5f6 
meta-fsl-ppc : 95d9f9aba81ccdae53011ac8c6fbbc2605b9cedc 
poky : 5e3e2e0cbb0a49986f4653e64c4c8d2b5461645e 


This is an automated message from
The Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder
Email: elizabeth.flana...@intel.com 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Cleanly moving files from one package to another

2015-12-10 Thread Martin Jansa 
On Wed, Dec 09, 2015 at 08:19:40PM +, Bryan Evenson wrote:
> All,
> 
> I'm on poky/dizzy-1.7.3 and I'm using opkg for a package manager.  I have a 
> few script files that are part of one package that really belong with 
> another.  So I updated both recipes, removed the file from one recipe and 
> added it to the other recipe.  I built everything, made the opkg feed repo 
> and tried to upgrade with "opkg update; opkg upgrade" to see how clean the 
> upgrade was.  For each script file I moved from one package to the other I 
> get an error message of the form:
> 
> * check_data_file_clashes: Package A wants to install file 
> /path/to/script/file
> But that file is already provided by package  * B
> 
> I know I can do "opkg upgrade --force-overwrite", but I'd like to make recipe 
> changes so that it upgrades cleanly.  All I've done in the recipes is remove 
> the script files from the FILES variable and the do_install step of one 
> recipe and added the script to the FILES variable and do_install step of the 
> other recipe.  I know update-alternatives can be used if more than one 
> package provides the same binary, but is that necessary in this case when 
> transferring ownership to another package?  Is there anything else I can do 
> in the recipes to prevent the opkg install errors?

Have you tried to set
RREPLACES_ = ""
?

If the old package should be removed completely during opkg upgrade,
then you'll need to set whole combo, that is
RREPLACES,RCONFLICTS,RPROVIDES.

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[linux-yocto] [PATCH 1/1] yaffs2: Add patch to fix missing checkpoint

2015-12-10 Thread zhe.he 
From: He Zhe 

Signed-off-by: He Zhe 
---
 .../yaffs2-fix-missing-checkpoint-on-yaffs.patch   | 85 ++
 features/yaffs2/yaffs2.scc |  1 +
 2 files changed, 86 insertions(+)
 create mode 100644 features/yaffs2/yaffs2-fix-missing-checkpoint-on-yaffs.patch

diff --git a/features/yaffs2/yaffs2-fix-missing-checkpoint-on-yaffs.patch 
b/features/yaffs2/yaffs2-fix-missing-checkpoint-on-yaffs.patch
new file mode 100644
index 000..cd7cc58
--- /dev/null
+++ b/features/yaffs2/yaffs2-fix-missing-checkpoint-on-yaffs.patch
@@ -0,0 +1,85 @@
+From fcdadf7cdb9659c76808ff5fc2f105c56436e6a8 Mon Sep 17 00:00:00 2001
+From: He Zhe 
+Date: Wed, 2 Dec 2015 01:31:31 -0500
+Subject: [PATCH] fs/yaffs2: fix missing checkpoint on yaffs
+
+For yaffs file system, the mode of reading or writing is restricted at
+four pointer where are mnt->mnt_flags,mnt->mnt_sb->s_flags,mtd->flags
+and dev->read_only,the first three is used handle file and file
+system(eg,remount) operation, and last one(dev->read_only) almost is used
+handle checkpoint of yaffs2. However, in current code, the dev->read_only
+only can be changed at first time when the yaffs2 file system is mounted,
+later it can't be changed again(eg,mount -o remount), the result is that
+the checkpoint's saving operation always can't succeed if you set readonly
+mode for yaffs2 file system when it is mounted at the first time.
+
+To fix this issue, we implement yaffs_remount_fs() which allows the
+rootfs to be remounted as r/w.
+
+Signed-off-by: Wenlin Kang 
+Signed-off-by: He Zhe 
+---
+ fs/yaffs2/yaffs_vfs.c | 39 +++
+ 1 file changed, 39 insertions(+)
+
+diff --git a/fs/yaffs2/yaffs_vfs.c b/fs/yaffs2/yaffs_vfs.c
+index 52177c1..16251d5 100644
+--- a/fs/yaffs2/yaffs_vfs.c
 b/fs/yaffs2/yaffs_vfs.c
+@@ -2614,7 +2614,45 @@ static int yaffs_sync_fs(struct super_block *sb)
+   return 0;
+ }
+ 
++/* the function only is used to change dev->read_only when this file system
++ * is remounted.
++ */
++static int yaffs_remount_fs(struct super_block *sb, int *flags, char *data)
++{
++  int read_only = 0;
++  struct mtd_info *mtd;
++  struct yaffs_dev *dev = 0;
++
++  /* Get the device */
++  mtd = get_mtd_device(NULL, MINOR(sb->s_dev));
++  if (!mtd) {
++  yaffs_trace(YAFFS_TRACE_ALWAYS,
++  "MTD device #%u doesn't appear to exist",
++  MINOR(sb->s_dev));
++  return 1;
++  }
+ 
++  /* Check it's NAND */
++  if (mtd->type != MTD_NANDFLASH) {
++  yaffs_trace(YAFFS_TRACE_ALWAYS,
++  "MTD device is not NAND it's type %d",
++  mtd->type);
++  return 1;
++  }
++
++  read_only = ((*flags & MS_RDONLY) != 0);
++  if (!read_only && !(mtd->flags & MTD_WRITEABLE)) {
++  read_only = 1;
++  printk(KERN_INFO
++ "yaffs: mtd is read only, setting superblock read only");
++  *flags |= MS_RDONLY;
++  }
++
++  dev = sb->s_fs_info;
++  dev->read_only = read_only;
++
++  return 0;
++}
+ 
+ static const struct super_operations yaffs_super_ops = {
+   .statfs = yaffs_statfs,
+@@ -2636,6 +2674,7 @@ static const struct super_operations yaffs_super_ops = {
+ #ifdef YAFFS_HAS_WRITE_SUPER
+   .write_super = yaffs_write_super,
+ #endif
++  .remount_fs = yaffs_remount_fs,
+ };
+ 
+ struct yaffs_options {
+-- 
+1.9.1
+
diff --git a/features/yaffs2/yaffs2.scc b/features/yaffs2/yaffs2.scc
index 2026f71..07e2653 100644
--- a/features/yaffs2/yaffs2.scc
+++ b/features/yaffs2/yaffs2.scc
@@ -13,3 +13,4 @@ patch 
yaffs2-switch-simple-generic_file_aio_read-users-to-.patch
 patch yaffs2-use-write_iter-variants-of-__-generic_file_ai.patch
 patch yaffs2-implement-splice_write-via-write_iter.patch
 patch yaffs2-fix-memory-leak-in-mount-umount.patch
+patch yaffs2-fix-missing-checkpoint-on-yaffs.patch
-- 
2.3.5

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

Re: [yocto] Custom kernel headers and SDK

2015-12-10 Thread Longchamp, Valentin 
Hi Martin,

Thanks a lot for the suggestion. I had in the meantime come to a simliar 
solution: define a linux-XXX-headers recipe in our own meta layer where I 
install the missing kernel headers and then I add this linux-XXX-headers-dev 
package to our SDK's sysroot thanks to TARGET_TOOLCHAIN_TASK.
Your implementation looks fine and I am going to pick some ideas from it.

However, I have stumbled upon another problem with this approach: it works well 
if you add new files to the kernel headers. We unforntunately have at least one 
uapi file (i2c.h to name it) that is present in the standard kernel headers 
where we have our own version with some additions/extensions. If I install our 
version from ou linux-XXX-headers recipe, bitbake (correctly) complains that 
this file is provided by 2 packages (linux-libc-headers and linux-XXX-headers). 
And here I really don't know how to solve this issue. Any ideas/suggestions ?

Thanks

Valentin

From: Vuille, Martin (Martin) [vmar...@avaya.com]
Sent: Wednesday, December 09, 2015 5:40 PM
To: Longchamp, Valentin; yocto@yoctoproject.org
Cc: Brunck, Holger
Subject: RE: Custom kernel headers and SDK

Hi Valentin,

Not sure whether this the “canonical” Yocto way, but here’s how we solved
the same issue.

First, let me say that we use a BSP from our technology partner, and have
our own meta-XXX layer for customization.


-  Created a .bbappend in our layer for the kernel recipe

-  In the .bbappend

o   add a do_install_append task that creates directory ${D}${includedir}/XXX
and installs the required headers from kernel source into that
directory

o   add a new package: PACKAGES += “ XXX-kernel-headers”

o   specify the files for that package: FILES_XXX-kernel-headers = 
“${includedir}/XXX/*”

-  In the recipe for the SDK, include the package XXX-kernel-headers

MV

From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Longchamp, Valentin
Sent: December 08, 2015 4:06 PM
To: yocto@yoctoproject.org
Cc: Brunck, Holger
Subject: [yocto] Custom kernel headers and SDK


Hello,

We are currently migrating our Embedded Linux software and the corresponding
small in house distribution to Yocto. We are small Linux team and we provide and
maintain the toolchain, kernel and base distribution for a broader team of
software developers that build the applications for our hardware.

So far, we have been able to use Yocto to build our whole software (kernel,
minimal distribution and application software) by adding our minimal meta-layer
and defining stuff there and it works great.

Since the application devs are "not interested" in our distro nor in the
compiler, we want to make them available for them thanks to the SDK which is a
great fit for this use case. So far it works very well and we are currently
working on adapting the build system to the SDK.

And here comes my question. We have however our own kernel sources that extend
the headers for a few "in-house" drivers. From the warning in linux-libc-headers
(http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc),
I understand that it should be avoided to recreate a recipe for the kernel
headers to avoid having the libc "machinified". From yocto, I could get the
custom headers thanks to STAGING_KERNEL_DIR. However, we need these custom
headers from "outside" of yocto, when using the SDK.

I have found 2 ways to install them into the sysroot and thus SDK:
- either by adding the kernel-devsrc to the SDK that installs them into
/usr/src/kernel by default.
- or by adding something similar to what is proposed in this mailing-list
discussion to our kernel recipe:
https://lists.yoctoproject.org/pipermail/linux-yocto/2014-April/002178.html

The problem with these 2 solutions is that sysroot contains:
1) the sanitized kernel headers at in sysroot/usr/include/linux
2) our custom headers at sysroot/usr/src/kernel/include/linux

and when I add a -I option in the CFLAGS for 2), I get conflicts since the SDK
automatically looks first in sysroot/usr/include.

Here is an example of the current errors I get with 1) and 2) in both the -I 
path:

>  from plat/icndrv/hdlc/mpc8xxx_scc/src/libhdlc-km.c:2:
>

[linux-yocto] [PATCH 0/1] Add patch to fix missing checkpoint on yaffs2, for yocto-4.1

2015-12-10 Thread zhe.he 
From: He Zhe 

Please apply this set of patches on yocto-4.1 branch from
git://git.yoctoproject.org/yocto-kernel-cache

He Zhe (1):
  yaffs2: Add patch to fix missing checkpoint

 .../yaffs2-fix-missing-checkpoint-on-yaffs.patch   | 85 ++
 features/yaffs2/yaffs2.scc |  1 +
 2 files changed, 86 insertions(+)
 create mode 100644 features/yaffs2/yaffs2-fix-missing-checkpoint-on-yaffs.patch

-- 
2.3.5

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

[linux-yocto] [PATCH 0/1] Add patch to fix missing checkpoint on yaffs2, for master

2015-12-10 Thread zhe.he 
From: He Zhe 

Please apply this set of patches on master branch from
git://git.yoctoproject.org/yocto-kernel-cache

He Zhe (1):
  yaffs2: Add patch to fix missing checkpoint

 .../yaffs2-fix-missing-checkpoint-on-yaffs.patch   | 85 ++
 features/yaffs2/yaffs2.scc |  1 +
 2 files changed, 86 insertions(+)
 create mode 100644 features/yaffs2/yaffs2-fix-missing-checkpoint-on-yaffs.patch

-- 
2.3.5

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

[linux-yocto] [PATCH 1/1] yaffs2: Add patch to fix missing checkpoint

2015-12-10 Thread zhe.he 
From: He Zhe 

Signed-off-by: He Zhe 
---
 .../yaffs2-fix-missing-checkpoint-on-yaffs.patch   | 85 ++
 features/yaffs2/yaffs2.scc |  1 +
 2 files changed, 86 insertions(+)
 create mode 100644 features/yaffs2/yaffs2-fix-missing-checkpoint-on-yaffs.patch

diff --git a/features/yaffs2/yaffs2-fix-missing-checkpoint-on-yaffs.patch 
b/features/yaffs2/yaffs2-fix-missing-checkpoint-on-yaffs.patch
new file mode 100644
index 000..cd7cc58
--- /dev/null
+++ b/features/yaffs2/yaffs2-fix-missing-checkpoint-on-yaffs.patch
@@ -0,0 +1,85 @@
+From fcdadf7cdb9659c76808ff5fc2f105c56436e6a8 Mon Sep 17 00:00:00 2001
+From: He Zhe 
+Date: Wed, 2 Dec 2015 01:31:31 -0500
+Subject: [PATCH] fs/yaffs2: fix missing checkpoint on yaffs
+
+For yaffs file system, the mode of reading or writing is restricted at
+four pointer where are mnt->mnt_flags,mnt->mnt_sb->s_flags,mtd->flags
+and dev->read_only,the first three is used handle file and file
+system(eg,remount) operation, and last one(dev->read_only) almost is used
+handle checkpoint of yaffs2. However, in current code, the dev->read_only
+only can be changed at first time when the yaffs2 file system is mounted,
+later it can't be changed again(eg,mount -o remount), the result is that
+the checkpoint's saving operation always can't succeed if you set readonly
+mode for yaffs2 file system when it is mounted at the first time.
+
+To fix this issue, we implement yaffs_remount_fs() which allows the
+rootfs to be remounted as r/w.
+
+Signed-off-by: Wenlin Kang 
+Signed-off-by: He Zhe 
+---
+ fs/yaffs2/yaffs_vfs.c | 39 +++
+ 1 file changed, 39 insertions(+)
+
+diff --git a/fs/yaffs2/yaffs_vfs.c b/fs/yaffs2/yaffs_vfs.c
+index 52177c1..16251d5 100644
+--- a/fs/yaffs2/yaffs_vfs.c
 b/fs/yaffs2/yaffs_vfs.c
+@@ -2614,7 +2614,45 @@ static int yaffs_sync_fs(struct super_block *sb)
+   return 0;
+ }
+ 
++/* the function only is used to change dev->read_only when this file system
++ * is remounted.
++ */
++static int yaffs_remount_fs(struct super_block *sb, int *flags, char *data)
++{
++  int read_only = 0;
++  struct mtd_info *mtd;
++  struct yaffs_dev *dev = 0;
++
++  /* Get the device */
++  mtd = get_mtd_device(NULL, MINOR(sb->s_dev));
++  if (!mtd) {
++  yaffs_trace(YAFFS_TRACE_ALWAYS,
++  "MTD device #%u doesn't appear to exist",
++  MINOR(sb->s_dev));
++  return 1;
++  }
+ 
++  /* Check it's NAND */
++  if (mtd->type != MTD_NANDFLASH) {
++  yaffs_trace(YAFFS_TRACE_ALWAYS,
++  "MTD device is not NAND it's type %d",
++  mtd->type);
++  return 1;
++  }
++
++  read_only = ((*flags & MS_RDONLY) != 0);
++  if (!read_only && !(mtd->flags & MTD_WRITEABLE)) {
++  read_only = 1;
++  printk(KERN_INFO
++ "yaffs: mtd is read only, setting superblock read only");
++  *flags |= MS_RDONLY;
++  }
++
++  dev = sb->s_fs_info;
++  dev->read_only = read_only;
++
++  return 0;
++}
+ 
+ static const struct super_operations yaffs_super_ops = {
+   .statfs = yaffs_statfs,
+@@ -2636,6 +2674,7 @@ static const struct super_operations yaffs_super_ops = {
+ #ifdef YAFFS_HAS_WRITE_SUPER
+   .write_super = yaffs_write_super,
+ #endif
++  .remount_fs = yaffs_remount_fs,
+ };
+ 
+ struct yaffs_options {
+-- 
+1.9.1
+
diff --git a/features/yaffs2/yaffs2.scc b/features/yaffs2/yaffs2.scc
index 7e54fdb..077c238 100644
--- a/features/yaffs2/yaffs2.scc
+++ b/features/yaffs2/yaffs2.scc
@@ -16,3 +16,4 @@ patch yaffs2-fix-memory-leak-in-mount-umount.patch
 patch yaffs2-replace-f_dentry-to-f_path.dentry.patch
 patch yaffs2-remove-read-and-write-methods.patch
 patch fs-yaffs2-Fix-a-judgement-logic-for-ACL-operations.patch
+patch yaffs2-fix-missing-checkpoint-on-yaffs.patch
-- 
2.3.5

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

Re: [yocto] Computing transaction Error

2015-12-10 Thread Khem Raj 

> On Dec 10, 2015, at 6:31 AM, Yukatharsani Jeyachandra 
>  wrote:
> 
> Hi All,
> 
> I am getting the following error while running my bsp image.
> 
> Loading cache...
> Updating cache...  [100%]
> 
> Computing transaction...error: Can't install 
> packagegroup-mrvl-bsp-1.0-r17.1@bg4ct: no package provides amp
> 
> Any idea what might go wrong ?


you have a package called amp which is actually empty so it gets removed from 
final package list but the package group still has the depepndency
so you can use ALLOW_EMPTY in amp recipe or your run time dependency in package 
group is wrong it should probably be some other package coming out
of same recipe thats building amp. May be a  library

> 
> Thanks and Regards,
> Yukatharsani J.
> 
> On 09-12-2015 19:21, Yukatharsani Jeyachandra wrote:
>> Hi All,
>> 
>> I am trying to build my meta-bsp layer using external linaro 
>> toolchain path.
>>  But i am getting some issues since i set EXTERNAL_TOOLCHAIN path in 
>> local.conf file.
>>  Is there any way to customize my meta layer alone to take external 
>> linaro tool chain not other general meta layers.
>> 
>> Thanks and Regards,
>> Yukatharsani J.
>> 
>> 
>> On 29-10-2015 11:19, Khem Raj wrote:
>>> On Wed, Oct 28, 2015 at 10:15 PM, YUKATHARSANI JEYACHANDRA
>>>  wrote:
 Hi,
 
 I am trying to build kernel image for new hardware.
 
 So, I prefer to use my linux 3.x version with specific changes.
 
 I want bitbake to fetch the local path of my linux.
 
 Is it possible to specify the local path in SRC_URI.
>>> yes. use file:///path/to/linux.tar or even you can use externalsrc and
>>> point it to your tree during development.
>>> read through
>>> http://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html#building-software-from-an-external-source
>>> 
 
 Thanks and Regards,
 
 Yukatharsani J.
 
 
 
 
 
 
 From: yocto-boun...@yoctoproject.org  on
 behalf of Andres Sagot 
 Sent: Thursday, October 29, 2015 9:49 AM
 To: yocto@yoctoproject.org
 Subject: [yocto] Kernel Version Dependency in BB Recipe
 
 Hello Yocto Community,
 
 I did a search and found a great deal about layer dependencies, but I am
 still not clear on how or if it is possible to add a kernel version
 dependency to a BB recipe. I would like to bitbake to report an error if it
 attempts to build my custom package with an unsupported version of Linux.
 
 Thank you and best regards,
 Andres
 
 --
 ___
 yocto mailing list
 yocto@yoctoproject.org
 https://lists.yoctoproject.org/listinfo/yocto
 
>>> .
>>> 
>> 
> 
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Best practice for building a large amount of source files

2015-12-10 Thread Burton, Ross 
On 10 December 2015 at 21:16, Michael Habibi  wrote:

> What is the best option for adding all of these and compiling? As far as I
> know, you have to do one of the following:
>
> 1) Use a fetch that fetches a tarball with all your source, or a repo with
> all of your source
> 2) Use a million-line long SRC_URI assignment to include every file that
> your application uses.
>
> Is there a third (or fourth) option that I may have missed?
>

(1) is definitely my recommendation, separate the application development
from the recipe to build the application.

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

[yocto] Best practice for building a large amount of source files

2015-12-10 Thread Michael Habibi 
If I have some source I want to bring into my layer, for example:

Recipe dir:
meta-mylayer/recipes-management/myapplication/myapplication_1.0/

What is the best option for adding all of these and compiling? As far as I
know, you have to do one of the following:

1) Use a fetch that fetches a tarball with all your source, or a repo with
all of your source
2) Use a million-line long SRC_URI assignment to include every file that
your application uses.

Is there a third (or fourth) option that I may have missed?

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

Re: [yocto] Best practice for building a large amount of source files

2015-12-10 Thread Michael Habibi 
Ross, I will likely try a different workflow if we enter production
environment with yocto. Right now I am just doing yocto integration testing
myself, and want to simplify things as much as possible for myself :)

On Thu, Dec 10, 2015 at 3:54 PM, Burton, Ross  wrote:

>
> On 10 December 2015 at 21:16, Michael Habibi  wrote:
>
>> What is the best option for adding all of these and compiling? As far as
>> I know, you have to do one of the following:
>>
>> 1) Use a fetch that fetches a tarball with all your source, or a repo
>> with all of your source
>> 2) Use a million-line long SRC_URI assignment to include every file that
>> your application uses.
>>
>> Is there a third (or fourth) option that I may have missed?
>>
>
> (1) is definitely my recommendation, separate the application development
> from the recipe to build the application.
>
> Ross
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Best practice for building a large amount of source files

2015-12-10 Thread Burton, Ross 
On 10 December 2015 at 22:07, Michael Habibi  wrote:

> Ross, I will likely try a different workflow if we enter production
> environment with yocto. Right now I am just doing yocto integration testing
> myself, and want to simplify things as much as possible for myself :)
>

A simply workflow would be a local git repo with all the sources in,  and
then a recipe with a git SRC_URI pointing at the local directory.

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

Re: [yocto] Best practice for building a large amount of source files

2015-12-10 Thread Jeremy A. Puhlman 



On 12/10/2015 1:16 PM, Michael Habibi wrote:

If I have some source I want to bring into my layer, for example:

Recipe dir:
meta-mylayer/recipes-management/myapplication/myapplication_1.0/of source files>


What is the best option for adding all of these and compiling? As far 
as I know, you have to do one of the following:


1) Use a fetch that fetches a tarball with all your source, or a repo 
with all of your source
2) Use a million-line long SRC_URI assignment to include every file 
that your application uses.


Is there a third (or fourth) option that I may have missed?
Not necessarily best practice, but it is something that bitbake has 
supported.


If you create a directory under myapplication_1.0 that is unique and not 
an override, you can specify the directory name

as the SRC_URI and bitbake will pull the directory and its contents in.

Something like 
meta-mylayer/recipes-management/myapplication/myapplication_1.0/mysources/of source files>


and SRC_URI file://mysources

It should work.

Something like the following:

> find recipes/
recipes/
recipes/myapp
recipes/myapp/files
recipes/myapp/files/mysources
recipes/myapp/files/mysources/Makefile
recipes/myapp/myapp_1.0.bb
> cat recipes/myapp/myapp_1.0.bb
LICENSE="MIT"
LIC_FILES_CHKSUM = 
"file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"


SRC_URI = "file://mysources"

S="${WORKDIR}/mysources"



Michael






--
Jeremy A. Puhlman
jpuhl...@mvista.com

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

Re: [yocto] Select make target for cmake

2015-12-10 Thread Burton, Ross 
On 10 December 2015 at 17:24, Philipp, Damian 
wrote:

> A Google search didn't turn up anything, so I looked through
> cmake.bbclass, autotools.bbclass and base.bbclass. The source indicated
> that the variable EXTRA_OEMAKE could be abused to inject a make target -
> however, setting EXTRA_OEMAKE = "server" in my recipe did *not* exclude the
> client binaries from the resulting image. In any case, I would prefer a
> clean solution over abusing implementation details.


A clearer way would be to do:

do_compile() {
oe_runmake server
}

It's possible that the compile phase is building just the server, but then
install is building and installing everything.

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

Re: [yocto] How to use PREEMPT-RT Header in Yocto

2015-12-10 Thread Jeff Osier-Mixon 
Hi Michael - the Kernel Development Manual discusses using PREEMPT_RT here:
http://www.yoctoproject.org/docs/2.0/kernel-dev/kernel-dev.html#using-kernel-metadata-in-a-recipe

I hope that helps a bit

On Mon, Dec 7, 2015 at 6:57 AM, Baumann, Michael
 wrote:
> Hello everbody,
>
> I am trying to use the PREEMPT-RT patch, therefore I bitbake an image with 
> the linux-yocto-rt 4.1.8 kernel.
> The linux-yocto-rt kernel is built and runs in qemux86.
> Now I try to build an application which uses the sched_setattr to set 
> scheduling policy SCHED_DEADLINE from .
> My Bitbake fails to build this application because of wrong header files e.g.
>
> error: storage size of 'scheduling_attribut' isn't known
> struct sched_attr scheduling_attribut;
> and
> warning: implicit declaration of function 'sched_setattr'
>
> in my created SDK (bitbake  -c populate_sdk) I have this 
> /usr/include/sched.h file:  http://pastebin.com/gaXejv6j
> I would have expect to find this file 
> http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-4.1/tree/include/linux/sched.h
>
> How do I use the correct header files from PREEMPT-RT patch in my yocto build 
> environment?
>
> Regards,
> Michael
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



-- 
Jeff Osier-Mixon
Open Source Community Architect, Intel Corporation
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] DNS nameserver on Yocto Daisy (resolvconf issue)

2015-12-10 Thread Andreas Enbacka 
Hello,

 

I have problems getting dns nameservers to work on my custom image built on
top of Yocto Daisy. I have tried added e.g., dns-nameservers entry to
/etc/network/interfaces, however running e.g., /etc/init.d/networking
restart outputs the following error message:

 

resolvconf: Error: /etc/resolvconf/run/interface either does not exist or is
not a directory.

 

Checking using ls show that /etc/resolvconf/run is a symlink to
/var/run/resolvconf which does not exist. 

 

Anyone have some suggestion how to get resolvconf / dns resolving to work on
Yocto Daisy? 

 

Sincerely,

Andreas

 

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

[yocto] [meta-cgl][PATCH] heartbeat: Fix the broken url

2015-12-10 Thread b40527 
From: Zongchun Yu 

Signed-off-by: Zongchun Yu 
---
 meta-cgl-common/recipes-cgl/heartbeat/heartbeat_3.0.6.bb | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta-cgl-common/recipes-cgl/heartbeat/heartbeat_3.0.6.bb 
b/meta-cgl-common/recipes-cgl/heartbeat/heartbeat_3.0.6.bb
index af03843..7fbed11 100644
--- a/meta-cgl-common/recipes-cgl/heartbeat/heartbeat_3.0.6.bb
+++ b/meta-cgl-common/recipes-cgl/heartbeat/heartbeat_3.0.6.bb
@@ -28,7 +28,7 @@ LIC_FILES_CHKSUM = " \
 file://doc/COPYING.LGPL;md5=d8045f3b8f929c1cb29a1e3fd737b499 \
 "
 SRC_URI = " \
-http://hg.linux-ha.org/heartbeat-STABLE_3_0/archive/cceeb47a7d8f.tar.bz2 \
+http://hg.linux-ha.org/heartbeat-STABLE_3_0/archive/958e11be8686.tar.bz2 \
 file://membership-ccm-Makefile.am-fix-warning.patch \
 file://Makefile.am-not-chgrp-in-cross-compile.patch \
 file://configure.in-Error-and-warning-fix.patch \
@@ -36,9 +36,9 @@ SRC_URI = " \
 file://heartbeat-bootstrap-libtool.patch \
 file://heartbeat.service \
 "
-SRC_URI[md5sum] = "3a98cf97842b8a557728be4fb94c8c5d"
-SRC_URI[sha256sum] = 
"a76ec86cd60428f89536c635a5109cf1e9c7f20283874041a4306960e69952f4"
-S = "${WORKDIR}/Heartbeat-3-0-cceeb47a7d8f/"
+SRC_URI[md5sum] = "101c8f507b1f407468d5ef15ae6719da"
+SRC_URI[sha256sum] = 
"851d2add2c129fef9fede764fec80229e1f6e7295e0e979950d10258648b462c"
+S = "${WORKDIR}/Heartbeat-3-0-958e11be8686/"
 DEPENDS = "cluster-glue corosync gnutls"
 RDEPENDS_${PN} += "python"
 inherit autotools-brokensep pkgconfig useradd
-- 
1.8.3.2

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

Re: [yocto] in-tree defconfig

2015-12-10 Thread Bruce Ashfield 

On 12/09/2015 06:43 PM, Robert Berger wrote:

Hi,

This seems to do the trick:

https://github.com/RobertBerger/meta-mainline/blob/jethro-training-v4.1.x/multi-v7-ml/recipes-kernel/linux/linux-yocto-custom.inc



That's what I would have suggested. Set the kconfig mode so that in
tree config becomes the baseline.

In the upcoming release, I have an open bugzilla to tweak the way
that this works, and I should be able to detect that in tree
defconfig and make alldefconfig the default for that mode.

Let me know if you have other issues with it.

Bruce


Regards,

Robert



..."The scientific name for an animal that doesn't either run from or
fight its enemies is lunch." - Michael Friedman

My public pgp key is available,at:
http://pgp.mit.edu:11371/pks/lookup?op=get=0x90320BF1




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

[yocto] Select make target for cmake

2015-12-10 Thread Philipp, Damian 
Hello Yocto experts,

Is it possible to specify a make target (e.g., "make server" or "make client") 
in a recipe using cmake? I am writing a set of recipies for a software that is 
built from a single source tree and thus a single CMake configuration. The 
CMake configuration currently contains 3 targets, resulting in 3 separate 
binaries. We would like to control how these binaries are distributed to 
packages - currently we'd like to have bitbake build one package with the main 
application (e.g., a server application) and another package containing all 
other binaries (e.g., a set of client applications).

A Google search didn't turn up anything, so I looked through cmake.bbclass, 
autotools.bbclass and base.bbclass. The source indicated that the variable 
EXTRA_OEMAKE could be abused to inject a make target - however, setting 
EXTRA_OEMAKE = "server" in my recipe did *not* exclude the client binaries from 
the resulting image. In any case, I would prefer a clean solution over abusing 
implementation details.

Regards,
Damian

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

Re: [yocto] [[AUH] 4/6] testimage/ptest: Add require of ptest-pkgs in EXTRA_IMAGE_FEATURES.

2015-12-10 Thread Paul Eggleton 
On Tue, 01 Dec 2015 16:03:39 Aníbal Limón wrote:
> Instead of add manually the ptest packages use IMAGE_FEATURE to
> install ptest packages this save time validating if ptest pkg
> exist.
> 
> Signed-off-by: Aníbal Limón 
> ---
>  README   | 3 ++-
>  modules/testimage.py | 5 ++---
>  upgradehelper.py | 5 +
>  3 files changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/README b/README
> index 1c8eba1..63c3b39 100644
> --- a/README
> +++ b/README
> @@ -108,7 +108,8 @@ file:
>  --- snip ---
>  INHERIT += "testimage"
> 
> -EXTRA_IMAGE_FEATURES = "debug-tweaks package-management"
> +DISTRO_FEATURES_append = " ptest"
> +EXTRA_IMAGE_FEATURES = "debug-tweaks package-management ptest-pkgs"
>  # testimage/ptest only work with rpm
>  PACKAGE_CLASSES = "package_rpm"
>  --- snip ---
> diff --git a/modules/testimage.py b/modules/testimage.py
> index e410111..52e2592 100644
> --- a/modules/testimage.py
> +++ b/modules/testimage.py
> @@ -60,11 +60,10 @@ class TestImage():
>  # for provide access to the target
>  if ptest:
>  pkgs_out.append("dropbear")
> +pkgs_out.append("ptest-runner")
> 
>  for c in pkgs:
>  pkgs_out.append(c['PN'])
> -if ptest:
> -pkgs_out.append("%s-ptest" % c['PN'])
> 
>  return ' '.join(pkgs_out)
> 
> @@ -122,7 +121,7 @@ class TestImage():
>  ptest_pkgs = self._get_ptest_pkgs()
> 
>  os.environ['CORE_IMAGE_EXTRA_INSTALL'] = \
> -self._get_pkgs_to_install(ptest_pkgs, True)
> +self._get_pkgs_to_install(ptest_pkgs, ptest=True)
>  I( "   building core-image-minimal for %s ..." % machine)
>  self.bb.complete("core-image-minimal", machine)
> 
> diff --git a/upgradehelper.py b/upgradehelper.py
> index db39601..5a2b844 100755
> --- a/upgradehelper.py
> +++ b/upgradehelper.py
> @@ -242,6 +242,11 @@ class Updater(object):
>" please add to conf/local.conf.")
>  exit(1)
> 
> +if not "ptest-pkgs" in
> self.base_env['EXTRA_IMAGE_FEATURES']: 
> +E("
> testimage/ptest requires ptest-pkgs in EXTRA_IMAGE_FEATURES"\ 
> +
>  " please add to conf/local.conf.")
> +exit(1)
> +

Strictly speaking this isn't really the proper test - the proper test is that 
ptest-pkgs is in IMAGE_FEATURES *for the image being built and tested* (not 
necessarily the global configuration). We can deal with this at some point in 
the future though.

Cheers,
Paul

-- 

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

[yocto] systemd postinstall start service

2015-12-10 Thread Dvorkin Dmitry 

Hello!

I have a recipe that can be installed into image using postinstall RPM 
scriptlet only.

It's an archive wrapped with a shell script.
During the do_rootfs step this RPM is installed such a way: executional 
archive placed into /opt/.

Then during the first system load systemd runs it's postinstall scriptlet

scriptlet is simple:

/opt/my_server.bin.sh
systemctl enable my_server.service
systemctl daemon-reload
systemctl start my_server.service

In my system when systemd runs this postinstall scriptlet it's executed, 
system is loaded, service is enabled, but not started.

service state is "enabled, but inactive (died)"
During the postinstall scriptlet execution at systemd first load I see 
message that my service is stopping instead of starting.

After reboot my_server.service is enabled and started.

Looks like systemd doesn't want to start service or it stopping it 
immediately after postinstall.

What can I do to start it on first load after postinstall ?

my_service.service have such a settings:

[Unit]
Description=my_server
After=syslog.target

[Service]
Type=simple
Restart=on-failure

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

Re: [yocto] Cleanly moving files from one package to another

2015-12-10 Thread Martin Jansa 
On Thu, Dec 10, 2015 at 02:15:05PM +, Bryan Evenson wrote:
> Martin,
> 
> > -Original Message-
> > From: Martin Jansa [mailto:martin.ja...@gmail.com]
> > Sent: Thursday, December 10, 2015 4:20 AM
> > To: Bryan Evenson 
> > Cc: yocto@yoctoproject.org
> > Subject: Re: [yocto] Cleanly moving files from one package to another
> > 
> > On Wed, Dec 09, 2015 at 08:19:40PM +, Bryan Evenson wrote:
> > > All,
> > >
> > > I'm on poky/dizzy-1.7.3 and I'm using opkg for a package manager.  I have 
> > > a
> > few script files that are part of one package that really belong with 
> > another.
> > So I updated both recipes, removed the file from one recipe and added it to
> > the other recipe.  I built everything, made the opkg feed repo and tried to
> > upgrade with "opkg update; opkg upgrade" to see how clean the upgrade
> > was.  For each script file I moved from one package to the other I get an 
> > error
> > message of the form:
> > >
> > > * check_data_file_clashes: Package A wants to install file
> > /path/to/script/file
> > > But that file is already provided by package  * B
> > >
> > > I know I can do "opkg upgrade --force-overwrite", but I'd like to make
> > recipe changes so that it upgrades cleanly.  All I've done in the recipes is
> > remove the script files from the FILES variable and the do_install step of 
> > one
> > recipe and added the script to the FILES variable and do_install step of the
> > other recipe.  I know update-alternatives can be used if more than one
> > package provides the same binary, but is that necessary in this case when
> > transferring ownership to another package?  Is there anything else I can do 
> > in
> > the recipes to prevent the opkg install errors?
> > 
> > Have you tried to set
> > RREPLACES_ = ""
> > ?
> 
> I haven't tried that because I'm not replacing a package.  Both packages 
> still exist on the system and are both needed, it's just that ownership of 
> one of the files is being transferred from one package to another.  Would I 
> still use RREPLACES even if I want to keep both packages on the system?
> 
> Specifically in this case, I have some script files for scheduled tasks that 
> were part of one of my self-made packages.  However, they really belong with 
> cronie since this is what is calling the scripts.  So I removed the script 
> files from my self-made package and added them to cronie.  My package has 
> other files still associated with it (that do belong with it) installed on my 
> system.  So I want to keep both packages on my system, but I just want to 
> change ownership of these script files from my package to cronie.  Is 
> RREPLACES the tool for this job?

> Is RREPLACES the tool for this job?

Yes, see
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

opkg should work the same.

> > If the old package should be removed completely during opkg upgrade, then
> > you'll need to set whole combo, that is RREPLACES,RCONFLICTS,RPROVIDES.

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Cleanly moving files from one package to another

2015-12-10 Thread Bryan Evenson 
Martin,

> -Original Message-
> From: Martin Jansa [mailto:martin.ja...@gmail.com]
> Sent: Thursday, December 10, 2015 4:20 AM
> To: Bryan Evenson 
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Cleanly moving files from one package to another
> 
> On Wed, Dec 09, 2015 at 08:19:40PM +, Bryan Evenson wrote:
> > All,
> >
> > I'm on poky/dizzy-1.7.3 and I'm using opkg for a package manager.  I have a
> few script files that are part of one package that really belong with another.
> So I updated both recipes, removed the file from one recipe and added it to
> the other recipe.  I built everything, made the opkg feed repo and tried to
> upgrade with "opkg update; opkg upgrade" to see how clean the upgrade
> was.  For each script file I moved from one package to the other I get an 
> error
> message of the form:
> >
> > * check_data_file_clashes: Package A wants to install file
> /path/to/script/file
> > But that file is already provided by package  * B
> >
> > I know I can do "opkg upgrade --force-overwrite", but I'd like to make
> recipe changes so that it upgrades cleanly.  All I've done in the recipes is
> remove the script files from the FILES variable and the do_install step of one
> recipe and added the script to the FILES variable and do_install step of the
> other recipe.  I know update-alternatives can be used if more than one
> package provides the same binary, but is that necessary in this case when
> transferring ownership to another package?  Is there anything else I can do in
> the recipes to prevent the opkg install errors?
> 
> Have you tried to set
> RREPLACES_ = ""
> ?

I haven't tried that because I'm not replacing a package.  Both packages still 
exist on the system and are both needed, it's just that ownership of one of the 
files is being transferred from one package to another.  Would I still use 
RREPLACES even if I want to keep both packages on the system?

Specifically in this case, I have some script files for scheduled tasks that 
were part of one of my self-made packages.  However, they really belong with 
cronie since this is what is calling the scripts.  So I removed the script 
files from my self-made package and added them to cronie.  My package has other 
files still associated with it (that do belong with it) installed on my system. 
 So I want to keep both packages on my system, but I just want to change 
ownership of these script files from my package to cronie.  Is RREPLACES the 
tool for this job?

Thanks,
Bryan

> 
> If the old package should be removed completely during opkg upgrade, then
> you'll need to set whole combo, that is RREPLACES,RCONFLICTS,RPROVIDES.
> 
> --
> Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Computing transaction Error

2015-12-10 Thread Yukatharsani Jeyachandra 

Hi All,

I am getting the following error while running my bsp image.

Loading cache...
Updating cache...  [100%]

Computing transaction...error: Can't install 
packagegroup-mrvl-bsp-1.0-r17.1@bg4ct: no package provides amp


Any idea what might go wrong ?

Thanks and Regards,
Yukatharsani J.

On 09-12-2015 19:21, Yukatharsani Jeyachandra wrote:

Hi All,

 I am trying to build my meta-bsp layer using external linaro 
toolchain path.
  But i am getting some issues since i set EXTERNAL_TOOLCHAIN 
path in local.conf file.
  Is there any way to customize my meta layer alone to take 
external linaro tool chain not other general meta layers.


Thanks and Regards,
Yukatharsani J.


On 29-10-2015 11:19, Khem Raj wrote:

On Wed, Oct 28, 2015 at 10:15 PM, YUKATHARSANI JEYACHANDRA
 wrote:

Hi,

I am trying to build kernel image for new hardware.

So, I prefer to use my linux 3.x version with specific changes.

I want bitbake to fetch the local path of my linux.

Is it possible to specify the local path in SRC_URI.

yes. use file:///path/to/linux.tar or even you can use externalsrc and
point it to your tree during development.
read through
http://www.yoctoproject.org/docs/1.8/dev-manual/dev-manual.html#building-software-from-an-external-source 





Thanks and Regards,

Yukatharsani J.






From: yocto-boun...@yoctoproject.org 
 on

behalf of Andres Sagot 
Sent: Thursday, October 29, 2015 9:49 AM
To: yocto@yoctoproject.org
Subject: [yocto] Kernel Version Dependency in BB Recipe

Hello Yocto Community,

I did a search and found a great deal about layer dependencies, but 
I am

still not clear on how or if it is possible to add a kernel version
dependency to a BB recipe. I would like to bitbake to report an 
error if it
attempts to build my custom package with an unsupported version of 
Linux.


Thank you and best regards,
Andres

--
___
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] Custom kernel headers and SDK

2015-12-10 Thread Vuille, Martin (Martin) 
Hi Valentin,

When we first encountered the need for custom kernel headers, I asked
a similar question to yours on this list. And what I learned from some of the
responses was that modifying the standard headers was fraught with
problems, including the issue that you raise.

Fortunately, we got away without having to modify and export any standard
headers, so I dodged that bullet.

Some ideas that come to mind:

- Can you install your customized version in ${includedir}/XXX and use the
  include path search order to make sure the compiler sees it first?

- Can you include the standard header in a "wrapper" header and make your
  customizations in the wrapper instead?

Regards,
MV

> -Original Message-
> From: Longchamp, Valentin [mailto:valentin.longch...@keymile.com]
> Sent: December 10, 2015 4:47 AM
> To: Vuille, Martin (Martin); yocto@yoctoproject.org
> Cc: Brunck, Holger
> Subject: RE: Custom kernel headers and SDK
> 
> Hi Martin,
> 
> Thanks a lot for the suggestion. I had in the meantime come to a simliar
> solution: define a linux-XXX-headers recipe in our own meta layer where I
> install the missing kernel headers and then I add this linux-XXX-headers-dev
> package to our SDK's sysroot thanks to TARGET_TOOLCHAIN_TASK.
> Your implementation looks fine and I am going to pick some ideas from it.
> 
> However, I have stumbled upon another problem with this approach: it
> works well if you add new files to the kernel headers. We unforntunately
> have at least one uapi file (i2c.h to name it) that is present in the standard
> kernel headers where we have our own version with some
> additions/extensions. If I install our version from ou linux-XXX-headers
> recipe, bitbake (correctly) complains that this file is provided by 2 packages
> (linux-libc-headers and linux-XXX-headers). And here I really don't know how
> to solve this issue. Any ideas/suggestions ?
> 
> Thanks
> 
> Valentin
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Cleanly moving files from one package to another

2015-12-10 Thread Bryan Evenson 
Martin,

> -Original Message-
> From: Martin Jansa [mailto:martin.ja...@gmail.com]
> Sent: Thursday, December 10, 2015 9:39 AM
> To: Bryan Evenson 
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Cleanly moving files from one package to another
> 
> On Thu, Dec 10, 2015 at 02:15:05PM +, Bryan Evenson wrote:
> > Martin,
> >
> > > -Original Message-
> > > From: Martin Jansa [mailto:martin.ja...@gmail.com]
> > > Sent: Thursday, December 10, 2015 4:20 AM
> > > To: Bryan Evenson 
> > > Cc: yocto@yoctoproject.org
> > > Subject: Re: [yocto] Cleanly moving files from one package to
> > > another
> > >
> > > On Wed, Dec 09, 2015 at 08:19:40PM +, Bryan Evenson wrote:
> > > > All,
> > > >
> > > > I'm on poky/dizzy-1.7.3 and I'm using opkg for a package manager.
> > > > I have a
> > > few script files that are part of one package that really belong with
> another.
> > > So I updated both recipes, removed the file from one recipe and
> > > added it to the other recipe.  I built everything, made the opkg
> > > feed repo and tried to upgrade with "opkg update; opkg upgrade" to
> > > see how clean the upgrade was.  For each script file I moved from
> > > one package to the other I get an error message of the form:
> > > >
> > > > * check_data_file_clashes: Package A wants to install file
> > > /path/to/script/file
> > > > But that file is already provided by package  * B
> > > >
> > > > I know I can do "opkg upgrade --force-overwrite", but I'd like to
> > > > make
> > > recipe changes so that it upgrades cleanly.  All I've done in the
> > > recipes is remove the script files from the FILES variable and the
> > > do_install step of one recipe and added the script to the FILES
> > > variable and do_install step of the other recipe.  I know
> > > update-alternatives can be used if more than one package provides
> > > the same binary, but is that necessary in this case when
> > > transferring ownership to another package?  Is there anything else I can
> do in the recipes to prevent the opkg install errors?
> > >
> > > Have you tried to set
> > > RREPLACES_ = ""
> > > ?
> >
> > I haven't tried that because I'm not replacing a package.  Both packages 
> > still
> exist on the system and are both needed, it's just that ownership of one of
> the files is being transferred from one package to another.  Would I still use
> RREPLACES even if I want to keep both packages on the system?
> >
> > Specifically in this case, I have some script files for scheduled tasks that
> were part of one of my self-made packages.  However, they really belong
> with cronie since this is what is calling the scripts.  So I removed the 
> script files
> from my self-made package and added them to cronie.  My package has
> other files still associated with it (that do belong with it) installed on my
> system.  So I want to keep both packages on my system, but I just want to
> change ownership of these script files from my package to cronie.  Is
> RREPLACES the tool for this job?
> 
> > Is RREPLACES the tool for this job?
> 
> Yes, see
> https://www.debian.org/doc/debian-policy/ch-relationships.html#s-
> replaces
> 
> opkg should work the same.

Now I'm having something happen that I haven't seen before with the PR service. 
 I updated my .bbappend to add the RREPLACES as you suggested, but bitbake 
didn't rebuild the package.  I tried doing bitbake -c clean and bitbake -c 
cleansstate and both times the built package had the same full version number 
as it did before I made the RREPLACES change.  I opened the ipk with Archive 
Manager and looked at DEBIAN/control, and there was no "Depends: " line in the 
control file.  Then I noticed that this .bbappend had "inherit pkgconfig" and 
it isn't needed in the .bbappend.  So while I was at it I deleted the line 
"inherit pkgconfig" and tried to build the package again (without issuing a 
bitbake -c clean first).  This time it built the package and the PR service 
incremented the version.  I opened the resulting ipk and looked at 
DEBIAN/control again, and this time there was a "Depends:" line in the control 
file.

Is changing RREPLACES not being seen as a metadata change by bitbake?  Is this 
a bug or is there something else I'm missing?

Thanks,
Bryan

> 
> > > If the old package should be removed completely during opkg upgrade,
> > > then you'll need to set whole combo, that is
> RREPLACES,RCONFLICTS,RPROVIDES.
> 
> --
> Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto