Re: [OE-core] [PATCH v2 2/2] wic: Add --embed-rootfs argument

2020-03-05 Thread Ricardo Ribalda Delgado
Hi Paul,

On Thu, Mar 5, 2020 at 10:37 AM Paul Barker  wrote:
>
> On Wed,  4 Mar 2020 15:49:36 +0100
> Ricardo Ribalda Delgado  wrote:
>
> > This option adds the content of a rootfs on a specific location on the
> > rootfs.
> >
> > It is very useful for making a partition that contains the rootfs for a
> > host and a target Eg:
> >
> > / -> Roofs for the host
> > /export/ -> Rootfs for the target (which will netboot)
> >
> > Although today we support making a partition for "/export" this might
> > not be compatible with some upgrade systems, or we might be limited by
> > the number of partitions.
> >
> > With this patch we can use something like:
> >
> > part / --source rootfs --embed-rootfs target-image /export --embed-rootfs 
> > target-image2 /export2
>
> I like this but it still leaves confusion between `--include-path` and
> --embed-rootfs` as they're similar but slightly different. Can we just modify
> `--include-path` to have this syntax?

I think they are different enough.

- include-path ads a file/folder
- embed-rootfs adds a rootfs, which is either a folder or a image.bb file.


>
> >
> > on the .wks file.
> >
> > Signed-off-by: Ricardo Ribalda Delgado 
> > ---
> >  scripts/lib/wic/help.py  |  8 
> >  scripts/lib/wic/ksparser.py  |  1 +
> >  scripts/lib/wic/partition.py |  1 +
> >  scripts/lib/wic/plugins/source/rootfs.py | 22 +-
> >  4 files changed, 31 insertions(+), 1 deletion(-)
> >
> > diff --git a/scripts/lib/wic/help.py b/scripts/lib/wic/help.py
> > index 4d342fcf05..140dc504cd 100644
> > --- a/scripts/lib/wic/help.py
> > +++ b/scripts/lib/wic/help.py
> > @@ -979,6 +979,14 @@ DESCRIPTION
> >   copies. This option only has an effect with the 
> > rootfs
> >   source plugin.
> >
> > + --embed-rootfs: This option is specific to wic. It embeds a 
> > rootfs into
> > + the given path to the resulting image. The option
> > + contains two fields, the roofs and the path, 
> > separated
> > + by a space. The rootfs follows the same logic as 
> > the
> > + rootfs-dir argument. Multiple options can be 
> > provided
> > + in order to embed multiple rootfs. This option 
> > only has
> > + an effect with the rootfs source plugin.
> > +
> >   --extra-space: This option is specific to wic. It adds extra
> >  space after the space filled by the content
> >  of the partition. The final size can go
> > diff --git a/scripts/lib/wic/ksparser.py b/scripts/lib/wic/ksparser.py
> > index 650b976223..64c8c1175e 100644
> > --- a/scripts/lib/wic/ksparser.py
> > +++ b/scripts/lib/wic/ksparser.py
> > @@ -138,6 +138,7 @@ class KickStart():
> >  part.add_argument('--align', type=int)
> >  part.add_argument('--exclude-path', nargs='+')
> >  part.add_argument('--include-path', nargs='+')
> > +part.add_argument('--embed-rootfs', nargs=2, action='append')
> >  part.add_argument("--extra-space", type=sizetype)
> >  part.add_argument('--fsoptions', dest='fsopts')
> >  part.add_argument('--fstype', default='vfat',
> > diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
> > index 2d95f78439..13857df82f 100644
> > --- a/scripts/lib/wic/partition.py
> > +++ b/scripts/lib/wic/partition.py
> > @@ -31,6 +31,7 @@ class Partition():
> >  self.extra_space = args.extra_space
> >  self.exclude_path = args.exclude_path
> >  self.include_path = args.include_path
> > +self.embed_rootfs = args.embed_rootfs
> >  self.fsopts = args.fsopts
> >  self.fstype = args.fstype
> >  self.label = args.label
> > diff --git a/scripts/lib/wic/plugins/source/rootfs.py 
> > b/scripts/lib/wic/plugins/source/rootfs.py
> > index 40419a64b3..089aaea477 100644
> > --- a/scripts/lib/wic/plugins/source/rootfs.py
> > +++ b/scripts/lib/wic/plugins/source/rootfs.py
> > @@ -17,6 +17,7 @@ import shutil
> >  import sys
> >
> >  from oe.path import copyhardlinktree, copytree
> > +from pathlib import Path
> >
> >  from wic import WicError
> >  from wic.pluginbase import SourcePlugin
> > @@ -80,7 +81,7 @@ class RootfsPlugin(SourcePlug

Re: [OE-core] [PATCH 1/2] wic: Fix permissions when using exclude or include path

2020-03-05 Thread Ricardo Ribalda Delgado
Hi Paul

On Thu, Mar 5, 2020 at 10:32 AM Paul Barker  wrote:
>
> On Wed, 4 Mar 2020 11:02:47 +0100
> Ricardo Ribalda Delgado  wrote:
>
> > Hi Paul
> >
> > On Wed, Mar 4, 2020 at 10:53 AM Paul Barker  wrote:
> > >
> > > On Wed,  4 Mar 2020 09:34:37 +0100
> > > Ricardo Ribalda Delgado  wrote:
> > >
> > > > When parameters include_path or exclude_path are passed to the rootfs
> > > > plugin, it will copy the partition content into a folder and make all
> > > > the modifications there.
> > > >
> > > > This is done using copyhardlinktree(), which does not take into
> > > > consideration the content of the pseudo folder, which contains the
> > > > information about the right permissions and ownership of the folders.
> > >
> > > How are you running wic here? In the do_image_wic task it's executed under
> > > pseudo so all this is handled already. Executing wic outside of bitbake 
> > > may
> > > need some more testing here.
> >
> > I am running wic outside bitbake. But even if it is run under bitbake,
> > it should also fail. The pseudo directory needs to be present on the
> > target image
>
> If you're running wic outside of bitbake, is there any guarantee that pseudo
> is available?

Yes, the same guarantee that the ext3_tools are available. So I
believe we are safe here. Actually in my docker pseudo is not
installed and when I invoke with wic, everything is fine.

>
> >
> > >
> > > >
> > > > This results in a rootfs owned by the user that is running the wic
> > > > command (usually UID 1000), which makes some rootfs unbootable.
> > > >
> > > > To fix this we copy the content of the pseudo folders to the new folder
> > > > and modify the pseudo database using the "pseudo -B" command.
> > > >
> > > > Signed-off-by: Ricardo Ribalda Delgado 
> > > > ---
> > > >  scripts/lib/wic/plugins/source/rootfs.py | 22 +++---
> > > >  1 file changed, 19 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/scripts/lib/wic/plugins/source/rootfs.py 
> > > > b/scripts/lib/wic/plugins/source/rootfs.py
> > > > index 705aeb5563..40419a64b3 100644
> > > > --- a/scripts/lib/wic/plugins/source/rootfs.py
> > > > +++ b/scripts/lib/wic/plugins/source/rootfs.py
> > > > @@ -16,11 +16,11 @@ import os
> > > >  import shutil
> > > >  import sys
> > > >
> > > > -from oe.path import copyhardlinktree
> > > > +from oe.path import copyhardlinktree, copytree
> > > >
> > > >  from wic import WicError
> > > >  from wic.pluginbase import SourcePlugin
> > > > -from wic.misc import get_bitbake_var
> > > > +from wic.misc import get_bitbake_var, exec_native_cmd
> > > >
> > > >  logger = logging.getLogger('wic')
> > > >
> > > > @@ -44,6 +44,15 @@ class RootfsPlugin(SourcePlugin):
> > > >
> > > >  return os.path.realpath(image_rootfs_dir)
> > > >
> > > > +@staticmethod
> > > > +def __get_pseudo(native_sysroot, rootfs):
> > > > +pseudo = "export PSEUDO_PREFIX=%s/usr;" % native_sysroot
> > > > +pseudo += "export PSEUDO_LOCALSTATEDIR=%s;" % 
> > > > os.path.join(rootfs, "../pseudo")
> > > > +pseudo += "export PSEUDO_PASSWD=%s;" % rootfs
> > > > +pseudo += "export PSEUDO_NOSYMLINKEXP=1;"
> > > > +pseudo += "%s " % get_bitbake_var("FAKEROOTCMD")
> > > > +return pseudo
> > > > +
> > > >  @classmethod
> > > >  def do_prepare_partition(cls, part, source_params, cr, cr_workdir,
> > > >   oe_builddir, bootimg_dir, kernel_dir,
> > > > @@ -78,9 +87,16 @@ class RootfsPlugin(SourcePlugin):
> > > >
> > > >  if os.path.lexists(new_rootfs):
> > > >  shutil.rmtree(os.path.join(new_rootfs))
> > > > -
> > > >  copyhardlinktree(part.rootfs_dir, new_rootfs)
> > > >
> > > > +if os.path.lexists(os.path.join(new_rootfs, "../pseudo")):
> > > > +shutil.rmtree(os.path.join(new_rootfs, "../pseudo"))
> > > > +copytree(os.path.join(part.rootfs_dir

[OE-core] [PATCH v2 1/2] wic: Fix permissions when using exclude or include path

2020-03-04 Thread Ricardo Ribalda Delgado
When parameters include_path or exclude_path are passed to the rootfs
plugin, it will copy the partition content into a folder and make all
the modifications there.

This is done using copyhardlinktree(), which does not take into
consideration the content of the pseudo folder, which contains the
information about the right permissions and ownership of the folders.

This results in a rootfs owned by the user that is running the wic
command (usually UID 1000), which makes some rootfs unbootable.

To fix this we copy the content of the pseudo folders to the new folder
and modify the pseudo database using the "pseudo -B" command.

Signed-off-by: Ricardo Ribalda Delgado 
---
 scripts/lib/wic/plugins/source/rootfs.py | 22 +++---
 1 file changed, 19 insertions(+), 3 deletions(-)

diff --git a/scripts/lib/wic/plugins/source/rootfs.py 
b/scripts/lib/wic/plugins/source/rootfs.py
index 705aeb5563..40419a64b3 100644
--- a/scripts/lib/wic/plugins/source/rootfs.py
+++ b/scripts/lib/wic/plugins/source/rootfs.py
@@ -16,11 +16,11 @@ import os
 import shutil
 import sys
 
-from oe.path import copyhardlinktree
+from oe.path import copyhardlinktree, copytree
 
 from wic import WicError
 from wic.pluginbase import SourcePlugin
-from wic.misc import get_bitbake_var
+from wic.misc import get_bitbake_var, exec_native_cmd
 
 logger = logging.getLogger('wic')
 
@@ -44,6 +44,15 @@ class RootfsPlugin(SourcePlugin):
 
 return os.path.realpath(image_rootfs_dir)
 
+@staticmethod
+def __get_pseudo(native_sysroot, rootfs):
+pseudo = "export PSEUDO_PREFIX=%s/usr;" % native_sysroot
+pseudo += "export PSEUDO_LOCALSTATEDIR=%s;" % os.path.join(rootfs, 
"../pseudo")
+pseudo += "export PSEUDO_PASSWD=%s;" % rootfs
+pseudo += "export PSEUDO_NOSYMLINKEXP=1;"
+pseudo += "%s " % get_bitbake_var("FAKEROOTCMD")
+return pseudo
+
 @classmethod
 def do_prepare_partition(cls, part, source_params, cr, cr_workdir,
  oe_builddir, bootimg_dir, kernel_dir,
@@ -78,9 +87,16 @@ class RootfsPlugin(SourcePlugin):
 
 if os.path.lexists(new_rootfs):
 shutil.rmtree(os.path.join(new_rootfs))
-
 copyhardlinktree(part.rootfs_dir, new_rootfs)
 
+if os.path.lexists(os.path.join(new_rootfs, "../pseudo")):
+shutil.rmtree(os.path.join(new_rootfs, "../pseudo"))
+copytree(os.path.join(part.rootfs_dir, "../pseudo"),
+ os.path.join(new_rootfs, "../pseudo"))
+pseudo_cmd = "%s -B -m %s -M %s" % 
(cls.__get_pseudo(native_sysroot,new_rootfs),
+part.rootfs_dir, new_rootfs)
+exec_native_cmd(pseudo_cmd, native_sysroot)
+
 for path in part.include_path or []:
 copyhardlinktree(path, new_rootfs)
 
-- 
2.25.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH v2 2/2] wic: Add --embed-rootfs argument

2020-03-04 Thread Ricardo Ribalda Delgado
This option adds the content of a rootfs on a specific location on the
rootfs.

It is very useful for making a partition that contains the rootfs for a
host and a target Eg:

/ -> Roofs for the host
/export/ -> Rootfs for the target (which will netboot)

Although today we support making a partition for "/export" this might
not be compatible with some upgrade systems, or we might be limited by
the number of partitions.

With this patch we can use something like:

part / --source rootfs --embed-rootfs target-image /export --embed-rootfs 
target-image2 /export2

on the .wks file.

Signed-off-by: Ricardo Ribalda Delgado 
---
 scripts/lib/wic/help.py  |  8 
 scripts/lib/wic/ksparser.py  |  1 +
 scripts/lib/wic/partition.py |  1 +
 scripts/lib/wic/plugins/source/rootfs.py | 22 +-
 4 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/scripts/lib/wic/help.py b/scripts/lib/wic/help.py
index 4d342fcf05..140dc504cd 100644
--- a/scripts/lib/wic/help.py
+++ b/scripts/lib/wic/help.py
@@ -979,6 +979,14 @@ DESCRIPTION
  copies. This option only has an effect with the rootfs
  source plugin.
 
+ --embed-rootfs: This option is specific to wic. It embeds a rootfs 
into
+ the given path to the resulting image. The option
+ contains two fields, the roofs and the path, separated
+ by a space. The rootfs follows the same logic as the
+ rootfs-dir argument. Multiple options can be provided
+ in order to embed multiple rootfs. This option only 
has
+ an effect with the rootfs source plugin.
+
  --extra-space: This option is specific to wic. It adds extra
 space after the space filled by the content
 of the partition. The final size can go
diff --git a/scripts/lib/wic/ksparser.py b/scripts/lib/wic/ksparser.py
index 650b976223..64c8c1175e 100644
--- a/scripts/lib/wic/ksparser.py
+++ b/scripts/lib/wic/ksparser.py
@@ -138,6 +138,7 @@ class KickStart():
 part.add_argument('--align', type=int)
 part.add_argument('--exclude-path', nargs='+')
 part.add_argument('--include-path', nargs='+')
+part.add_argument('--embed-rootfs', nargs=2, action='append')
 part.add_argument("--extra-space", type=sizetype)
 part.add_argument('--fsoptions', dest='fsopts')
 part.add_argument('--fstype', default='vfat',
diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
index 2d95f78439..13857df82f 100644
--- a/scripts/lib/wic/partition.py
+++ b/scripts/lib/wic/partition.py
@@ -31,6 +31,7 @@ class Partition():
 self.extra_space = args.extra_space
 self.exclude_path = args.exclude_path
 self.include_path = args.include_path
+self.embed_rootfs = args.embed_rootfs
 self.fsopts = args.fsopts
 self.fstype = args.fstype
 self.label = args.label
diff --git a/scripts/lib/wic/plugins/source/rootfs.py 
b/scripts/lib/wic/plugins/source/rootfs.py
index 40419a64b3..089aaea477 100644
--- a/scripts/lib/wic/plugins/source/rootfs.py
+++ b/scripts/lib/wic/plugins/source/rootfs.py
@@ -17,6 +17,7 @@ import shutil
 import sys
 
 from oe.path import copyhardlinktree, copytree
+from pathlib import Path
 
 from wic import WicError
 from wic.pluginbase import SourcePlugin
@@ -80,7 +81,7 @@ class RootfsPlugin(SourcePlugin):
 
 new_rootfs = None
 # Handle excluded paths.
-if part.exclude_path or part.include_path:
+if part.exclude_path or part.include_path or part.embed_rootfs:
 # We need a new rootfs directory we can delete files from. Copy to
 # workdir.
 new_rootfs = os.path.realpath(os.path.join(cr_workdir, "rootfs%d" 
% part.lineno))
@@ -100,6 +101,25 @@ class RootfsPlugin(SourcePlugin):
 for path in part.include_path or []:
 copyhardlinktree(path, new_rootfs)
 
+for embed in part.embed_rootfs or []:
+[embed_rootfs, path] = embed
+#we need to remove the initial / for os.path.join to work
+if os.path.isabs(path):
+path = path[1:]
+if embed_rootfs in krootfs_dir:
+embed_rootfs = krootfs_dir[embed_rootfs]
+embed_rootfs = cls.__get_rootfs_dir(embed_rootfs)
+tar_file = os.path.realpath(os.path.join(cr_workdir, 
"aux.tar"))
+tar_cmd = "%s tar cpf %s -C %s ." % 
(cls.__get_pseudo(native_sysroot,
+ embed_rootfs), tar_file, 
embed_rootfs)
+exec_native_cmd(tar_cmd, native_sysroot)
+untar_cmd = "%s tar x

Re: [OE-core] [PATCH 2/2] wic: Add --embed-rootfs argument

2020-03-04 Thread Ricardo Ribalda Delgado
Hi Paul

On Wed, Mar 4, 2020 at 11:14 AM Ricardo Ribalda Delgado
 wrote:
>
> Hi Paul
>
> On Wed, Mar 4, 2020 at 11:09 AM Paul Barker  wrote:
> >
> > On Wed, 4 Mar 2020 10:56:20 +0100
> > Ricardo Ribalda Delgado  wrote:
> >
> > > Hi Paul
> > >
> > > Thanks for your reply
> > >
> > > On Wed, Mar 4, 2020 at 10:43 AM Paul Barker  wrote:
> > > >
> > > > On Wed,  4 Mar 2020 09:34:38 +0100
> > > > Ricardo Ribalda Delgado  wrote:
> > > >
> > > > > This option adds the content of a rootfs on a specific location on the
> > > > > rootfs.
> > > > >
> > > > > It is very useful for making a partition that contains the rootfs for 
> > > > > a
> > > > > host and a target Eg:
> > > > >
> > > > > / -> Roofs for the host
> > > > > /export/ -> Rootfs for the target (which will netboot)
> > > > >
> > > > > Although today we support making a partition for "/export" this might
> > > > > not be compatible with some upgrade systems, or we might be limited by
> > > > > the number of partitions.
> > > > >
> > > > > With this patch we can use something like:
> > > > >
> > > > > part / --source rootfs --embed-rootfs=target-image:/export
> > > >
> > > > I considered using a syntax like this for --include-path but I chose 
> > > > not to
> > > > as it's not easy to choose a separator. ':' is a valid character in a
> > > > directory name.
> > >
> > > I think we have to live with not being able to copy files to a
> > > directory with a colon :(
> >
> > I wouldn't like to place a limitation like that on users and I'd like to
> > avoid the proliferation of similar arguments here.
> >
> > How about modifying '--include-path' to take two arguments, a source path 
> > and
> > a destination prefix? The python argument parser should be able to handle
> > this and you can build a list of tuples (source_path, dest_prefix) when
> > parsing the arguments.
> >
> > The '--include-path' argument hasn't been part of a Yocto release yet it's
> > just on the master branch so I think if we're going to fix it with a 
> > breaking
> > change, now is definitely the time.
>
> That sounds good to me. I do not mind having two arguments. for
> embed-rootfs. and probably will look better on include-path

How do you think that the parameters should look like:

--embed-rootfs target-image /export target-image2 /export2
--embed-rootfs (target-image, /export) (target-image2, /export2)
 ??

Shall I change it for include-path and embed-rootfs or you want to
take care of include-path?

>
> >
> > >
> > > >
> > > > My approach is to handle this in two steps:
> > > >
> > > > 1) Add a new task before do_image_wic which creates an 'embedded-rootfs'
> > > >   directory and copies 'target-image' to 'embedded-rootfs/export'.
> > > >
> > > > 2) Use '--include-path=embedded-rootfs' in the wks file.
> > > >
> > >
> > > The biggest problem with that approach is permissions. We need files
> > > with UID 0, siticky bits, etc. We lose the pseudo database if we
> > > simply copy to a folder.
> > >
> > > Also, if we have a complex system with multiple partitions I prefer to
> > > handle all in a single .wks file instead of a script + wks file
> > >
> > > > >
> > > > > on the .wks file.
> > > > >
> > > > > Signed-off-by: Ricardo Ribalda Delgado 
> > > > > ---
> > > > >  scripts/lib/wic/help.py  |  7 +++
> > > > >  scripts/lib/wic/ksparser.py  |  1 +
> > > > >  scripts/lib/wic/partition.py |  1 +
> > > > >  scripts/lib/wic/plugins/source/rootfs.py | 20 +++-
> > > > >  4 files changed, 28 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/scripts/lib/wic/help.py b/scripts/lib/wic/help.py
> > > > > index 4d342fcf05..67a33e6a65 100644
> > > > > --- a/scripts/lib/wic/help.py
> > > > > +++ b/scripts/lib/wic/help.py
> > > > > @@ -979,6 +979,13 @@ DESCRIPTION
> > > > >   copies. This option only has an effect with 
> > > > > the rootfs
> > > > >  

Re: [OE-core] [PATCH 2/2] wic: Add --embed-rootfs argument

2020-03-04 Thread Ricardo Ribalda Delgado
Hi Paul

On Wed, Mar 4, 2020 at 11:09 AM Paul Barker  wrote:
>
> On Wed, 4 Mar 2020 10:56:20 +0100
> Ricardo Ribalda Delgado  wrote:
>
> > Hi Paul
> >
> > Thanks for your reply
> >
> > On Wed, Mar 4, 2020 at 10:43 AM Paul Barker  wrote:
> > >
> > > On Wed,  4 Mar 2020 09:34:38 +0100
> > > Ricardo Ribalda Delgado  wrote:
> > >
> > > > This option adds the content of a rootfs on a specific location on the
> > > > rootfs.
> > > >
> > > > It is very useful for making a partition that contains the rootfs for a
> > > > host and a target Eg:
> > > >
> > > > / -> Roofs for the host
> > > > /export/ -> Rootfs for the target (which will netboot)
> > > >
> > > > Although today we support making a partition for "/export" this might
> > > > not be compatible with some upgrade systems, or we might be limited by
> > > > the number of partitions.
> > > >
> > > > With this patch we can use something like:
> > > >
> > > > part / --source rootfs --embed-rootfs=target-image:/export
> > >
> > > I considered using a syntax like this for --include-path but I chose not 
> > > to
> > > as it's not easy to choose a separator. ':' is a valid character in a
> > > directory name.
> >
> > I think we have to live with not being able to copy files to a
> > directory with a colon :(
>
> I wouldn't like to place a limitation like that on users and I'd like to
> avoid the proliferation of similar arguments here.
>
> How about modifying '--include-path' to take two arguments, a source path and
> a destination prefix? The python argument parser should be able to handle
> this and you can build a list of tuples (source_path, dest_prefix) when
> parsing the arguments.
>
> The '--include-path' argument hasn't been part of a Yocto release yet it's
> just on the master branch so I think if we're going to fix it with a breaking
> change, now is definitely the time.

That sounds good to me. I do not mind having two arguments. for
embed-rootfs. and probably will look better on include-path

>
> >
> > >
> > > My approach is to handle this in two steps:
> > >
> > > 1) Add a new task before do_image_wic which creates an 'embedded-rootfs'
> > >   directory and copies 'target-image' to 'embedded-rootfs/export'.
> > >
> > > 2) Use '--include-path=embedded-rootfs' in the wks file.
> > >
> >
> > The biggest problem with that approach is permissions. We need files
> > with UID 0, siticky bits, etc. We lose the pseudo database if we
> > simply copy to a folder.
> >
> > Also, if we have a complex system with multiple partitions I prefer to
> > handle all in a single .wks file instead of a script + wks file
> >
> > > >
> > > > on the .wks file.
> > > >
> > > > Signed-off-by: Ricardo Ribalda Delgado 
> > > > ---
> > > >  scripts/lib/wic/help.py  |  7 +++
> > > >  scripts/lib/wic/ksparser.py  |  1 +
> > > >  scripts/lib/wic/partition.py |  1 +
> > > >  scripts/lib/wic/plugins/source/rootfs.py | 20 +++-
> > > >  4 files changed, 28 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/scripts/lib/wic/help.py b/scripts/lib/wic/help.py
> > > > index 4d342fcf05..67a33e6a65 100644
> > > > --- a/scripts/lib/wic/help.py
> > > > +++ b/scripts/lib/wic/help.py
> > > > @@ -979,6 +979,13 @@ DESCRIPTION
> > > >   copies. This option only has an effect with 
> > > > the rootfs
> > > >   source plugin.
> > > >
> > > > + --embed-rootfs: This option is specific to wic. It embeds a 
> > > > rootfs into
> > > > + the given path to the resulting image. The 
> > > > option
> > > > + contains two fields, the roofs and the path, 
> > > > separated
> > > > + by a colon. The rootfs follows the same logic 
> > > > as the
> > > > + rootfs-dir argument. This option only has an 
> > > > effect
> > > > + with the rootfs source plugin.
> > > > +
> > > >   --extra-space: This option is specific to wic. It adds extra
> > > >   

Re: [OE-core] [PATCH 1/2] wic: Fix permissions when using exclude or include path

2020-03-04 Thread Ricardo Ribalda Delgado
Hi Paul

On Wed, Mar 4, 2020 at 10:53 AM Paul Barker  wrote:
>
> On Wed,  4 Mar 2020 09:34:37 +0100
> Ricardo Ribalda Delgado  wrote:
>
> > When parameters include_path or exclude_path are passed to the rootfs
> > plugin, it will copy the partition content into a folder and make all
> > the modifications there.
> >
> > This is done using copyhardlinktree(), which does not take into
> > consideration the content of the pseudo folder, which contains the
> > information about the right permissions and ownership of the folders.
>
> How are you running wic here? In the do_image_wic task it's executed under
> pseudo so all this is handled already. Executing wic outside of bitbake may
> need some more testing here.

I am running wic outside bitbake. But even if it is run under bitbake,
it should also fail. The pseudo directory needs to be present on the
target image

>
> >
> > This results in a rootfs owned by the user that is running the wic
> > command (usually UID 1000), which makes some rootfs unbootable.
> >
> > To fix this we copy the content of the pseudo folders to the new folder
> > and modify the pseudo database using the "pseudo -B" command.
> >
> > Signed-off-by: Ricardo Ribalda Delgado 
> > ---
> >  scripts/lib/wic/plugins/source/rootfs.py | 22 +++---
> >  1 file changed, 19 insertions(+), 3 deletions(-)
> >
> > diff --git a/scripts/lib/wic/plugins/source/rootfs.py 
> > b/scripts/lib/wic/plugins/source/rootfs.py
> > index 705aeb5563..40419a64b3 100644
> > --- a/scripts/lib/wic/plugins/source/rootfs.py
> > +++ b/scripts/lib/wic/plugins/source/rootfs.py
> > @@ -16,11 +16,11 @@ import os
> >  import shutil
> >  import sys
> >
> > -from oe.path import copyhardlinktree
> > +from oe.path import copyhardlinktree, copytree
> >
> >  from wic import WicError
> >  from wic.pluginbase import SourcePlugin
> > -from wic.misc import get_bitbake_var
> > +from wic.misc import get_bitbake_var, exec_native_cmd
> >
> >  logger = logging.getLogger('wic')
> >
> > @@ -44,6 +44,15 @@ class RootfsPlugin(SourcePlugin):
> >
> >  return os.path.realpath(image_rootfs_dir)
> >
> > +@staticmethod
> > +def __get_pseudo(native_sysroot, rootfs):
> > +pseudo = "export PSEUDO_PREFIX=%s/usr;" % native_sysroot
> > +pseudo += "export PSEUDO_LOCALSTATEDIR=%s;" % os.path.join(rootfs, 
> > "../pseudo")
> > +pseudo += "export PSEUDO_PASSWD=%s;" % rootfs
> > +pseudo += "export PSEUDO_NOSYMLINKEXP=1;"
> > +pseudo += "%s " % get_bitbake_var("FAKEROOTCMD")
> > +return pseudo
> > +
> >  @classmethod
> >  def do_prepare_partition(cls, part, source_params, cr, cr_workdir,
> >   oe_builddir, bootimg_dir, kernel_dir,
> > @@ -78,9 +87,16 @@ class RootfsPlugin(SourcePlugin):
> >
> >  if os.path.lexists(new_rootfs):
> >  shutil.rmtree(os.path.join(new_rootfs))
> > -
> >  copyhardlinktree(part.rootfs_dir, new_rootfs)
> >
> > +if os.path.lexists(os.path.join(new_rootfs, "../pseudo")):
> > +shutil.rmtree(os.path.join(new_rootfs, "../pseudo"))
> > +copytree(os.path.join(part.rootfs_dir, "../pseudo"),
> > + os.path.join(new_rootfs, "../pseudo"))
>
> I don't like stepping up the directory tree like this. We should be more
> explicit with the paths.

You are thinking on:
os.path.dirname(directory)

>
> > +pseudo_cmd = "%s -B -m %s -M %s" % 
> > (cls.__get_pseudo(native_sysroot,new_rootfs),
> > +part.rootfs_dir, 
> > new_rootfs)
> > +exec_native_cmd(pseudo_cmd, native_sysroot)
> > +
> >  for path in part.include_path or []:
> >  copyhardlinktree(path, new_rootfs)
>
>
>
> If this is the right approach I imagine you would also need to fix things up
> with pseudo after the copyhardlinktree call above.

I do not think it is needed. include_path does not contain its own
pseudo directory

>
> --
> Paul Barker
> Konsulko Group



-- 
Ricardo Ribalda
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 2/2] wic: Add --embed-rootfs argument

2020-03-04 Thread Ricardo Ribalda Delgado
Hi Paul

Thanks for your reply

On Wed, Mar 4, 2020 at 10:43 AM Paul Barker  wrote:
>
> On Wed,  4 Mar 2020 09:34:38 +0100
> Ricardo Ribalda Delgado  wrote:
>
> > This option adds the content of a rootfs on a specific location on the
> > rootfs.
> >
> > It is very useful for making a partition that contains the rootfs for a
> > host and a target Eg:
> >
> > / -> Roofs for the host
> > /export/ -> Rootfs for the target (which will netboot)
> >
> > Although today we support making a partition for "/export" this might
> > not be compatible with some upgrade systems, or we might be limited by
> > the number of partitions.
> >
> > With this patch we can use something like:
> >
> > part / --source rootfs --embed-rootfs=target-image:/export
>
> I considered using a syntax like this for --include-path but I chose not to
> as it's not easy to choose a separator. ':' is a valid character in a
> directory name.

I think we have to live with not being able to copy files to a
directory with a colon :(

>
> My approach is to handle this in two steps:
>
> 1) Add a new task before do_image_wic which creates an 'embedded-rootfs'
>   directory and copies 'target-image' to 'embedded-rootfs/export'.
>
> 2) Use '--include-path=embedded-rootfs' in the wks file.
>

The biggest problem with that approach is permissions. We need files
with UID 0, siticky bits, etc. We lose the pseudo database if we
simply copy to a folder.

Also, if we have a complex system with multiple partitions I prefer to
handle all in a single .wks file instead of a script + wks file

> >
> > on the .wks file.
> >
> > Signed-off-by: Ricardo Ribalda Delgado 
> > ---
> >  scripts/lib/wic/help.py  |  7 +++
> >  scripts/lib/wic/ksparser.py  |  1 +
> >  scripts/lib/wic/partition.py |  1 +
> >  scripts/lib/wic/plugins/source/rootfs.py | 20 +++-
> >  4 files changed, 28 insertions(+), 1 deletion(-)
> >
> > diff --git a/scripts/lib/wic/help.py b/scripts/lib/wic/help.py
> > index 4d342fcf05..67a33e6a65 100644
> > --- a/scripts/lib/wic/help.py
> > +++ b/scripts/lib/wic/help.py
> > @@ -979,6 +979,13 @@ DESCRIPTION
> >   copies. This option only has an effect with the 
> > rootfs
> >   source plugin.
> >
> > + --embed-rootfs: This option is specific to wic. It embeds a 
> > rootfs into
> > + the given path to the resulting image. The option
> > + contains two fields, the roofs and the path, 
> > separated
> > + by a colon. The rootfs follows the same logic as 
> > the
> > + rootfs-dir argument. This option only has an 
> > effect
> > + with the rootfs source plugin.
> > +
> >   --extra-space: This option is specific to wic. It adds extra
> >  space after the space filled by the content
> >  of the partition. The final size can go
> > diff --git a/scripts/lib/wic/ksparser.py b/scripts/lib/wic/ksparser.py
> > index 650b976223..d422e2a6bb 100644
> > --- a/scripts/lib/wic/ksparser.py
> > +++ b/scripts/lib/wic/ksparser.py
> > @@ -138,6 +138,7 @@ class KickStart():
> >  part.add_argument('--align', type=int)
> >  part.add_argument('--exclude-path', nargs='+')
> >  part.add_argument('--include-path', nargs='+')
> > +part.add_argument('--embed-rootfs', nargs='+')
> >  part.add_argument("--extra-space", type=sizetype)
> >  part.add_argument('--fsoptions', dest='fsopts')
> >  part.add_argument('--fstype', default='vfat',
> > diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
> > index 2d95f78439..13857df82f 100644
> > --- a/scripts/lib/wic/partition.py
> > +++ b/scripts/lib/wic/partition.py
> > @@ -31,6 +31,7 @@ class Partition():
> >  self.extra_space = args.extra_space
> >  self.exclude_path = args.exclude_path
> >  self.include_path = args.include_path
> > +self.embed_rootfs = args.embed_rootfs
> >  self.fsopts = args.fsopts
> >  self.fstype = args.fstype
> >  self.label = args.label
> > diff --git a/scripts/lib/wic/plugins/source/rootfs.py 
> > b/scripts/lib/wic/plugins/source/rootfs.py
> > index 40419a64b3..16359601dc 100644
> > --- a/scripts/lib/wic/plugins/source/rootfs.py
> > +++ b/scripts/lib/wic/plugins/source/r

[OE-core] [PATCH 2/2] wic: Add --embed-rootfs argument

2020-03-04 Thread Ricardo Ribalda Delgado
This option adds the content of a rootfs on a specific location on the
rootfs.

It is very useful for making a partition that contains the rootfs for a
host and a target Eg:

/ -> Roofs for the host
/export/ -> Rootfs for the target (which will netboot)

Although today we support making a partition for "/export" this might
not be compatible with some upgrade systems, or we might be limited by
the number of partitions.

With this patch we can use something like:

part / --source rootfs --embed-rootfs=target-image:/export

on the .wks file.

Signed-off-by: Ricardo Ribalda Delgado 
---
 scripts/lib/wic/help.py  |  7 +++
 scripts/lib/wic/ksparser.py  |  1 +
 scripts/lib/wic/partition.py |  1 +
 scripts/lib/wic/plugins/source/rootfs.py | 20 +++-
 4 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/scripts/lib/wic/help.py b/scripts/lib/wic/help.py
index 4d342fcf05..67a33e6a65 100644
--- a/scripts/lib/wic/help.py
+++ b/scripts/lib/wic/help.py
@@ -979,6 +979,13 @@ DESCRIPTION
  copies. This option only has an effect with the rootfs
  source plugin.
 
+ --embed-rootfs: This option is specific to wic. It embeds a rootfs 
into
+ the given path to the resulting image. The option
+ contains two fields, the roofs and the path, separated
+ by a colon. The rootfs follows the same logic as the
+ rootfs-dir argument. This option only has an effect
+ with the rootfs source plugin.
+
  --extra-space: This option is specific to wic. It adds extra
 space after the space filled by the content
 of the partition. The final size can go
diff --git a/scripts/lib/wic/ksparser.py b/scripts/lib/wic/ksparser.py
index 650b976223..d422e2a6bb 100644
--- a/scripts/lib/wic/ksparser.py
+++ b/scripts/lib/wic/ksparser.py
@@ -138,6 +138,7 @@ class KickStart():
 part.add_argument('--align', type=int)
 part.add_argument('--exclude-path', nargs='+')
 part.add_argument('--include-path', nargs='+')
+part.add_argument('--embed-rootfs', nargs='+')
 part.add_argument("--extra-space", type=sizetype)
 part.add_argument('--fsoptions', dest='fsopts')
 part.add_argument('--fstype', default='vfat',
diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
index 2d95f78439..13857df82f 100644
--- a/scripts/lib/wic/partition.py
+++ b/scripts/lib/wic/partition.py
@@ -31,6 +31,7 @@ class Partition():
 self.extra_space = args.extra_space
 self.exclude_path = args.exclude_path
 self.include_path = args.include_path
+self.embed_rootfs = args.embed_rootfs
 self.fsopts = args.fsopts
 self.fstype = args.fstype
 self.label = args.label
diff --git a/scripts/lib/wic/plugins/source/rootfs.py 
b/scripts/lib/wic/plugins/source/rootfs.py
index 40419a64b3..16359601dc 100644
--- a/scripts/lib/wic/plugins/source/rootfs.py
+++ b/scripts/lib/wic/plugins/source/rootfs.py
@@ -80,7 +80,7 @@ class RootfsPlugin(SourcePlugin):
 
 new_rootfs = None
 # Handle excluded paths.
-if part.exclude_path or part.include_path:
+if part.exclude_path or part.include_path or part.embed_rootfs:
 # We need a new rootfs directory we can delete files from. Copy to
 # workdir.
 new_rootfs = os.path.realpath(os.path.join(cr_workdir, "rootfs%d" 
% part.lineno))
@@ -100,6 +100,24 @@ class RootfsPlugin(SourcePlugin):
 for path in part.include_path or []:
 copyhardlinktree(path, new_rootfs)
 
+for embed in part.embed_rootfs or []:
+[embed_rootfs, path] = embed.split(":")
+#we need to remove the initial / for os.path.join to work
+if os.path.isabs(path):
+path = path[1:]
+if embed_rootfs in krootfs_dir:
+embed_rootfs = krootfs_dir[embed_rootfs]
+embed_rootfs = cls.__get_rootfs_dir(embed_rootfs)
+tar_file = os.path.realpath(os.path.join(cr_workdir, 
"aux.tar"))
+tar_cmd = "%s tar cpf %s -C %s ." % 
(cls.__get_pseudo(native_sysroot,
+ embed_rootfs), tar_file, 
embed_rootfs)
+exec_native_cmd(tar_cmd, native_sysroot)
+untar_cmd = "%s tar xf %s -C %s ." % 
(cls.__get_pseudo(native_sysroot, new_rootfs),
+  tar_file, 
os.path.join(new_rootfs, path))
+exec_native_cmd(untar_cmd, native_sysroot,
+cls.__get_pseudo(native_sysroot, new_rootfs))
+os.remove(tar_file)
+

[OE-core] [PATCH 1/2] wic: Fix permissions when using exclude or include path

2020-03-04 Thread Ricardo Ribalda Delgado
When parameters include_path or exclude_path are passed to the rootfs
plugin, it will copy the partition content into a folder and make all
the modifications there.

This is done using copyhardlinktree(), which does not take into
consideration the content of the pseudo folder, which contains the
information about the right permissions and ownership of the folders.

This results in a rootfs owned by the user that is running the wic
command (usually UID 1000), which makes some rootfs unbootable.

To fix this we copy the content of the pseudo folders to the new folder
and modify the pseudo database using the "pseudo -B" command.

Signed-off-by: Ricardo Ribalda Delgado 
---
 scripts/lib/wic/plugins/source/rootfs.py | 22 +++---
 1 file changed, 19 insertions(+), 3 deletions(-)

diff --git a/scripts/lib/wic/plugins/source/rootfs.py 
b/scripts/lib/wic/plugins/source/rootfs.py
index 705aeb5563..40419a64b3 100644
--- a/scripts/lib/wic/plugins/source/rootfs.py
+++ b/scripts/lib/wic/plugins/source/rootfs.py
@@ -16,11 +16,11 @@ import os
 import shutil
 import sys
 
-from oe.path import copyhardlinktree
+from oe.path import copyhardlinktree, copytree
 
 from wic import WicError
 from wic.pluginbase import SourcePlugin
-from wic.misc import get_bitbake_var
+from wic.misc import get_bitbake_var, exec_native_cmd
 
 logger = logging.getLogger('wic')
 
@@ -44,6 +44,15 @@ class RootfsPlugin(SourcePlugin):
 
 return os.path.realpath(image_rootfs_dir)
 
+@staticmethod
+def __get_pseudo(native_sysroot, rootfs):
+pseudo = "export PSEUDO_PREFIX=%s/usr;" % native_sysroot
+pseudo += "export PSEUDO_LOCALSTATEDIR=%s;" % os.path.join(rootfs, 
"../pseudo")
+pseudo += "export PSEUDO_PASSWD=%s;" % rootfs
+pseudo += "export PSEUDO_NOSYMLINKEXP=1;"
+pseudo += "%s " % get_bitbake_var("FAKEROOTCMD")
+return pseudo
+
 @classmethod
 def do_prepare_partition(cls, part, source_params, cr, cr_workdir,
  oe_builddir, bootimg_dir, kernel_dir,
@@ -78,9 +87,16 @@ class RootfsPlugin(SourcePlugin):
 
 if os.path.lexists(new_rootfs):
 shutil.rmtree(os.path.join(new_rootfs))
-
 copyhardlinktree(part.rootfs_dir, new_rootfs)
 
+if os.path.lexists(os.path.join(new_rootfs, "../pseudo")):
+shutil.rmtree(os.path.join(new_rootfs, "../pseudo"))
+copytree(os.path.join(part.rootfs_dir, "../pseudo"),
+ os.path.join(new_rootfs, "../pseudo"))
+pseudo_cmd = "%s -B -m %s -M %s" % 
(cls.__get_pseudo(native_sysroot,new_rootfs),
+part.rootfs_dir, new_rootfs)
+exec_native_cmd(pseudo_cmd, native_sysroot)
+
 for path in part.include_path or []:
 copyhardlinktree(path, new_rootfs)
 
-- 
2.25.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] Best practices: Multiple images on one partition.

2020-01-16 Thread Ricardo Ribalda Delgado
Hi Paul

It looks interesting, I guess I can use your code and extend it to
support complete file system instead of just a file. Will come back to
the list with a patch in case someone else finds it useful

Thanks

On Wed, Jan 15, 2020 at 2:53 PM Paul Barker  wrote:
>
> On Wed, 15 Jan 2020 at 13:05, Ricardo Ribalda Delgado
>  wrote:
> >
> > Hello
> >
> > I am trying to figure out the best way to achieve this. I have a
> > system with a host and a target. The target netboots form the host and
> > have a different package architecture.
> >
> > Usually I was solving this with one partition per image/machine,
> > combined using a .wks file like:
> >
> > part /export --source rootfs --rootfs-dir=target-image  --fstype=ext4
> > --label export --align 1024 --use-uuid --fsoptions defaults,ro
> > --extra-space 400M
> > part / --source rootfs --fstype=ext4 --label rootfs --align 1024
> > --use-uuid --fsoptions defaults,ro --extra-space 400M
> >
> > and then calling wic file after generating both images. ("wic create")
> >
> > This works fine, but now I need to combine both partitions into one.
> > The reason is that the partition needs to play nice with the current
> > OTA upgrade system.
> >
> > What would be the best way to do this?
> >
> > 1) Implement a new wic plugin, called something like muli-rootfs,
> > where I can specify multiple rootfs and in which directory to unpack
> > them
> >
> > 2) Implement a .bb file that combines the two images in one.
> >
> > do_install() {
> > tar -mzxf $HOST/host-image.tar.gz  -C ${D}/
> > tar -mzxf $HOST/target-image.tar.gz  -C ${D}/export
> > }
> >
> > 3) Another way that I am not aware :)
>
> I've recently added the `--include-path` option to wic on master which
> may be helpful here:
> https://git.openembedded.org/openembedded-core/commit/?id=d4cd27a9837426e809190548a83c6c7c76505114.
> My use case was multiple rootfs copies on different partitions, with
> extra files added to just one copy of the rootfs. But it may also be
> useful for this case.
>
> Thanks,
> Paul



-- 
Ricardo Ribalda
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] Best practices: Multiple images on one partition.

2020-01-15 Thread Ricardo Ribalda Delgado
Hello

I am trying to figure out the best way to achieve this. I have a
system with a host and a target. The target netboots form the host and
have a different package architecture.

Usually I was solving this with one partition per image/machine,
combined using a .wks file like:

part /export --source rootfs --rootfs-dir=target-image  --fstype=ext4
--label export --align 1024 --use-uuid --fsoptions defaults,ro
--extra-space 400M
part / --source rootfs --fstype=ext4 --label rootfs --align 1024
--use-uuid --fsoptions defaults,ro --extra-space 400M

and then calling wic file after generating both images. ("wic create")

This works fine, but now I need to combine both partitions into one.
The reason is that the partition needs to play nice with the current
OTA upgrade system.

What would be the best way to do this?

1) Implement a new wic plugin, called something like muli-rootfs,
where I can specify multiple rootfs and in which directory to unpack
them

2) Implement a .bb file that combines the two images in one.

do_install() {
tar -mzxf $HOST/host-image.tar.gz  -C ${D}/
tar -mzxf $HOST/target-image.tar.gz  -C ${D}/export
}

3) Another way that I am not aware :)

Thanks!
--
Ricardo Ribalda
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 0/2] Avoid build failures due to setscene errors

2020-01-09 Thread Ricardo Ribalda Delgado
Hi

I am also hitting this wall. Any reason why the original patches could
not be merged?

On Fri, Nov 29, 2019 at 5:49 PM Martin Jansa  wrote:
>
> On Wed, Aug 30, 2017 at 9:54 AM Martin Jansa  wrote:
>>
>> I agree with this patchset and it would be OK with IGNORE_SETSCENE_ERRORS 
>> conditional as well.
>>
>> We're also sometimes seeing these errors, sometime anticipated when cleaning 
>> shared sstate-cache on NFS server sometimes unexpected when NFS or network 
>> goes down for a minute and for some builds it happens between 
>> sstate_checkhashes()  and using the sstate.
>>
>> We normally stop all jenkins builds, until the cleanup is complete (there is 
>> jenkins job doing the cleanup, so it puts jenkins into stop mode, waits for 
>> all current jobs to finish which can take hours, then performs the cleanup 
>> and cancels the stop mode), but we cannot stop hundreds of developers using 
>> the same sstate-cache in local builds (especially when we cannot really know 
>> when exactly the job will have free jenkins to perform the cleanup) - 
>> luckily in local builds it doesn't hurt so bad, because the developers are 
>> more likely to ignore the error as long as the image was created, but in 
>> jenkins builds when bitbake returns error we cannot easily distinguish this 
>> case of "RP is intentionally warning us that something went wrong with 
>> sstate, but everything was built correctly in the end" and "something failed 
>> in the build and we weren't able to recover from that, maybe even the image 
>> wasn't created" - so we don't trigger the follow up actions like announcing 
>> new official
  builds or parsing release notes or automated testing.
>>
>> Yes we could add more logic to these CI jobs, to grep the logs to decide if 
>> this error was the only one which caused the bitbake to return error code 
>> and ignore the returned error in such case, but simple variable is easier to 
>> maintain (even for the cost of forking bitbake and oe-core) and will work 
>> for local builds as well.
>
>
>  I was using these 2 changes in my fork of oe-core and bitbake since they 
> were sent to the list, but today after getting a bunch of errors like this 
> from build which unfortunately wasn't using my forks and few questions about 
> why these errors aren't ignored from fellow developers I've finally found 
> time to improve our CI jobs to deal with this and ignore the bitbake return 
> code if it's reporting failure only because of these setscene fetcher 
> failures.
>
> If someone needs similar work around for bitbake behavior, here is what I did:
> https://github.com/webOS-ports/jenkins-jobs/pull/12
> yes, it's ugly, but it seems to work and is a bit better than forking oe-core 
> and bitbake just because of this issue.
>
> Regards,
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



-- 
Ricardo Ribalda
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] i2c-tools: Add missing RDEPEND

2019-10-17 Thread Ricardo Ribalda Delgado
Fixes:
 # decode-dimms
Can't locate Carp.pm in @INC (you may need to install the Carp module) (@INC 
contains: /usr/lib/perl5/site_perl/5.28.1/x86_64-linux 
/usr/lib/perl5/site_perl/5.28.1 /usr/lib/perl5/vendor_perl/5.28.1/x86_64-linux 
/usr/lib/perl5/vendor_perl/5.28.1 /usr/lib/perl5/5.28.1/x86_64-linux 
/usr/lib/perl5/5.28.1 .) at /usr/lib/perl5/5.28.1/Tie/Hash.pm line 190.
BEGIN failed--compilation aborted at /usr/lib/perl5/5.28.1/Tie/Hash.pm line 190.
Compilation failed in require at /usr/lib/perl5/5.28.1/x86_64-linux/POSIX.pm 
line 505.
Compilation failed in require at /usr/bin/decode-dimms line 41.
BEGIN failed--compilation aborted at /usr/bin/decode-dimms line 41.
root@qt5222:~# apt-get install perl-module-carp

Signed-off-by: Ricardo Ribalda Delgado 
---
 meta/recipes-devtools/i2c-tools/i2c-tools_4.1.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/i2c-tools/i2c-tools_4.1.bb 
b/meta/recipes-devtools/i2c-tools/i2c-tools_4.1.bb
index dcbd05aed4..c5761170aa 100644
--- a/meta/recipes-devtools/i2c-tools/i2c-tools_4.1.bb
+++ b/meta/recipes-devtools/i2c-tools/i2c-tools_4.1.bb
@@ -31,6 +31,7 @@ FILES_${PN}-misc = "${sbindir}/i2c-stub-from-dump \
 RDEPENDS_${PN}-misc = "${PN} perl perl-module-posix \
perl-module-constant perl-module-file-basename \
perl-module-fcntl perl-module-strict perl-module-vars \
+  perl-module-carp \
   "
 
 ALTERNATIVE_PRIORITY = "100"
-- 
2.23.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH v2] inetutils: Fix abort on invalid files

2019-08-07 Thread Ricardo Ribalda Delgado
When the code is compiled with  "-fstack-protector-strong
-D_FORTIFY_SOURCE=2", everytime ftpfd is asked for a non existent file,
it crashes with the following error:

*** buffer overflow detected ***:
Aborted

This seems to be a bug/feature of gcc. A bug has been open on their
bugzilla, and also inetutils have been posted with the proposed patch.

Without this patch, pxelinux fails to boot because it keeps asking the
server for the pxelinux.cfg/00-01-02-03-04 and never jumps to /default.

Signed-off-by: Ricardo Ribalda Delgado 
---
 .../inetutils/fix-buffer-fortify-tfpt.patch   | 25 +++
 .../inetutils/inetutils_1.9.4.bb  |  1 +
 2 files changed, 26 insertions(+)
 create mode 100644 
meta/recipes-connectivity/inetutils/inetutils/fix-buffer-fortify-tfpt.patch

diff --git 
a/meta/recipes-connectivity/inetutils/inetutils/fix-buffer-fortify-tfpt.patch 
b/meta/recipes-connectivity/inetutils/inetutils/fix-buffer-fortify-tfpt.patch
new file mode 100644
index 00..a91913cb51
--- /dev/null
+++ 
b/meta/recipes-connectivity/inetutils/inetutils/fix-buffer-fortify-tfpt.patch
@@ -0,0 +1,25 @@
+tftpd: Fix abort on error path
+
+When trying to fetch a non existent file, the app crashes with:
+
+*** buffer overflow detected ***: 
+Aborted
+
+
+Upstream-Status: Submitted 
[https://www.mail-archive.com/bug-inetutils@gnu.org/msg03036.html 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91205]
+Signed-off-by: Ricardo Ribalda Delgado 
+diff --git a/src/tftpd.c b/src/tftpd.c
+index 56002a0..144012f 100644
+--- a/src/tftpd.c
 b/src/tftpd.c
+@@ -864,9 +864,8 @@ nak (int error)
+   pe->e_msg = strerror (error - 100);
+   tp->th_code = EUNDEF;   /* set 'undef' errorcode */
+ }
+-  strcpy (tp->th_msg, pe->e_msg);
+   length = strlen (pe->e_msg);
+-  tp->th_msg[length] = '\0';
++  memcpy(tp->th_msg, pe->e_msg, length + 1);
+   length += 5;
+   if (sendto (peer, buf, length, 0, (struct sockaddr *) , fromlen) != 
length)
+ syslog (LOG_ERR, "nak: %m\n");
diff --git a/meta/recipes-connectivity/inetutils/inetutils_1.9.4.bb 
b/meta/recipes-connectivity/inetutils/inetutils_1.9.4.bb
index ac2e017d8b..684fbe09e1 100644
--- a/meta/recipes-connectivity/inetutils/inetutils_1.9.4.bb
+++ b/meta/recipes-connectivity/inetutils/inetutils_1.9.4.bb
@@ -22,6 +22,7 @@ SRC_URI = "${GNU_MIRROR}/inetutils/inetutils-${PV}.tar.gz \
file://inetutils-1.9-PATH_PROCNET_DEV.patch \
file://inetutils-only-check-pam_appl.h-when-pam-enabled.patch \
file://0001-rcp-fix-to-work-with-large-files.patch \
+   file://fix-buffer-fortify-tfpt.patch \
 "
 
 SRC_URI[md5sum] = "04852c26c47cc8c6b825f2b74f191f52"
-- 
2.20.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] OEDEM 2019

2019-07-31 Thread Ricardo Ribalda Delgado
If there are enough people interested it would be great a BoF, even if
it is "unofficial"


On Wed, Jul 31, 2019 at 6:45 PM Philip Balister  wrote:
>
> On 07/31/2019 05:48 AM, Ricardo Ribalda Delgado wrote:
> > BTW, Is there anything for Embedded Recipes or Plumbers?
>
> No. But we are always interested in improving communication with the
> larger community. Any suggestions what you would like to see at events
> like these?
>
> Philip
>
> >
> > On Tue, Jul 30, 2019 at 7:33 PM Philip Balister  wrote:
> >>
> >> We are working with the Yocto Project on a two day Summit event. This
> >> should implement part of the ideas from the the last couple of developer
> >> meetings.
> >>
> >> Philip
> >>
> >> On 07/30/2019 12:58 PM, Ruslan Bilovol wrote:
> >>> Hi all,
> >>>
> >>> Is there any plan to hold an OpenEmbedded developer meting
> >>> in Lyon, France around this year's ELCE 2019 (October 28-30)?
> >>>
> >>> I see that OEDEM 2019 page isn't created yet and I didn't find
> >>> any news in mailing lists yet:
> >>> https://www.openembedded.org/wiki/OEDEM_2019
> >>>
> >>> Thanks,
> >>> Ruslan
> >>>
> >> --
> >> ___
> >> Openembedded-core mailing list
> >> Openembedded-core@lists.openembedded.org
> >> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >
> >
> >



--
Ricardo Ribalda
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] OEDEM 2019

2019-07-31 Thread Ricardo Ribalda Delgado
BTW, Is there anything for Embedded Recipes or Plumbers?

On Tue, Jul 30, 2019 at 7:33 PM Philip Balister  wrote:
>
> We are working with the Yocto Project on a two day Summit event. This
> should implement part of the ideas from the the last couple of developer
> meetings.
>
> Philip
>
> On 07/30/2019 12:58 PM, Ruslan Bilovol wrote:
> > Hi all,
> >
> > Is there any plan to hold an OpenEmbedded developer meting
> > in Lyon, France around this year's ELCE 2019 (October 28-30)?
> >
> > I see that OEDEM 2019 page isn't created yet and I didn't find
> > any news in mailing lists yet:
> > https://www.openembedded.org/wiki/OEDEM_2019
> >
> > Thanks,
> > Ruslan
> >
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



-- 
Ricardo Ribalda
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [meta-oe][PATCH v2] fwts: Update to 19.06.00

2019-07-30 Thread Ricardo Ribalda Delgado
ping?

On Tue, Jul 23, 2019 at 10:04 PM Ricardo Ribalda Delgado
 wrote:
>
> Update to latest release.
>
> Since version 18.08.00, libbsd is a dependency:
> https://wiki.ubuntu.com/FirmwareTestSuite/ReleaseNotes/18.08.00
>
> Signed-off-by: Ricardo Ribalda Delgado 
> ---
>  .../fwts/0001-Remove-Werror-from-build.patch  | 22 ++---
>  ...t-logical-operand-warning-with-clang.patch | 84 ---
>  .../fwts/{fwts_git.bb => fwts_19.06.00.bb}| 11 +--
>  3 files changed, 15 insertions(+), 102 deletions(-)
>  delete mode 100644 
> meta-oe/recipes-test/fwts/fwts/0001-ignore-constant-logical-operand-warning-with-clang.patch
>  rename meta-oe/recipes-test/fwts/{fwts_git.bb => fwts_19.06.00.bb} (83%)
>
> diff --git 
> a/meta-oe/recipes-test/fwts/fwts/0001-Remove-Werror-from-build.patch 
> b/meta-oe/recipes-test/fwts/fwts/0001-Remove-Werror-from-build.patch
> index 611ccc8fc..6795ba849 100644
> --- a/meta-oe/recipes-test/fwts/fwts/0001-Remove-Werror-from-build.patch
> +++ b/meta-oe/recipes-test/fwts/fwts/0001-Remove-Werror-from-build.patch
> @@ -12,33 +12,33 @@ Upstream-Status: Pending
>   3 files changed, 3 insertions(+), 3 deletions(-)
>
>  diff --git a/src/Makefile.am b/src/Makefile.am
> -index 4daa9e8f..873f23eb 100644
> +index 62c9ba8..435ec23 100644
>  --- a/src/Makefile.am
>  +++ b/src/Makefile.am
>  @@ -14,7 +14,7 @@ AM_CPPFLAGS = \
> -   `pkg-config --silence-errors --cflags json` \
> -   `pkg-config --silence-errors --cflags json-c` \
> +   `pkg-config --silence-errors --cflags json` \
> +   `pkg-config --silence-errors --cflags json-c`   \
> -pthread `pkg-config --cflags glib-2.0 gio-2.0` \
> --  -Wall -Werror -Wextra
> -+  -Wall -Wextra
> +-  -Wall -Werror -Wextra   \
> ++  -Wall -Wextra   \
> +   -Wno-address-of-packed-member
>
>   bin_PROGRAMS = fwts
> -
>  diff --git a/src/lib/src/Makefile.am b/src/lib/src/Makefile.am
> -index fa232451..082403a2 100644
> +index 6bcf9f8..de89bf1 100644
>  --- a/src/lib/src/Makefile.am
>  +++ b/src/lib/src/Makefile.am
>  @@ -24,7 +24,7 @@ AM_CPPFLAGS = \
> `pkg-config --silence-errors --cflags json-c`   \
> `pkg-config --cflags glib-2.0 gio-2.0`  \
> -DDATAROOTDIR=\"$(datarootdir)\"\
> --  -Wall -Werror -Wextra
> -+  -Wall -Wextra
> +-  -Wall -Werror -Wextra   \
> ++  -Wall -Wextra   \
> +   -Wno-address-of-packed-member
>
>   pkglib_LTLIBRARIES = libfwts.la
> -
>  diff --git a/src/utilities/Makefile.am b/src/utilities/Makefile.am
> -index aa37de55..4d5297cc 100644
> +index 21f969e..82009a0 100644
>  --- a/src/utilities/Makefile.am
>  +++ b/src/utilities/Makefile.am
>  @@ -16,7 +16,7 @@
> diff --git 
> a/meta-oe/recipes-test/fwts/fwts/0001-ignore-constant-logical-operand-warning-with-clang.patch
>  
> b/meta-oe/recipes-test/fwts/fwts/0001-ignore-constant-logical-operand-warning-with-clang.patch
> deleted file mode 100644
> index ae3665b4d..0
> --- 
> a/meta-oe/recipes-test/fwts/fwts/0001-ignore-constant-logical-operand-warning-with-clang.patch
> +++ /dev/null
> @@ -1,84 +0,0 @@
> -From 5bd05ad8569880985ddf6d4c06ed927d388c297f Mon Sep 17 00:00:00 2001
> -From: Khem Raj 
> -Date: Wed, 19 Oct 2016 01:57:16 +
> -Subject: [PATCH] ignore constant-logical-operand warning with clang
> -
> -Signed-off-by: Khem Raj 
> -
> 
> - src/dmi/dmicheck/dmicheck.c| 3 +++
> - src/lib/src/fwts_acpi_tables.c | 5 +
> - src/uefi/uefirtauthvar/uefirtauthvar.c | 5 +
> - 3 files changed, 13 insertions(+)
> -
> -diff --git a/src/dmi/dmicheck/dmicheck.c b/src/dmi/dmicheck/dmicheck.c
> -index 3cca9db9..60fb758f 100644
>  a/src/dmi/dmicheck/dmicheck.c
> -+++ b/src/dmi/dmicheck/dmicheck.c
> -@@ -211,6 +211,8 @@ static const char *uuid_patterns[] = {
> -   "0A0A0A0A-0A0A-0A0A-0A0A-0A0A0A0A0A0A",
> -   NULL,
> - };
> -+#pragma clang diagnostic push
> -+#pragma clang diagnostic ignored "-Wunneeded-internal-declaration"
> -
> - static const fwts_chassis_type_map fwts_dmi_chassis_type[] = {
> -   { "Invalid",FWTS_SMBIOS_CHASSIS_INVALID },
> -@@ -251,6 +253,7 @@ static const fwts_chassis_type_map 
> fwts_dmi_chassis_type[] = {
> -   { "Mini PC",FWTS_SMBIOS_CHASSIS_MINI_PC },
> -   { "Stick PC",   FWTS_SMBIOS_CHASSIS_STICK_PC },
> - };
> -+#pragma clang diagnostic pop
> -
> - /* Remapping table from buggy version numbers to correct values */
> - static const fwts_dmi_version dmi_versions[] = {
&

Re: [OE-core] [PATCH] inetutils: Fix abort on invalid files

2019-07-30 Thread Ricardo Ribalda Delgado
ping?

On Fri, Jul 19, 2019 at 8:12 AM Ricardo Ribalda Delgado
 wrote:
>
> Hi Khem
>
> Indeed is due to that, but infortunately it is part of arpa/tftp.h .
> So the propossed solutionI believe that it is simpler.
>
> https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
>
> Also is what I have been suggested in #gcc
>
>
> Thanks!
>
> On Fri, Jul 19, 2019 at 12:39 AM Khem Raj  wrote:
> >
> > On Thu, Jul 18, 2019 at 2:10 PM Ricardo Ribalda Delgado
> >  wrote:
> > >
> > > Hi Khem
> > >
> > > I think the issue is that __memcpy_chk wrongly assume that the target
> > > size is 0. The origin size is calculated fine:
> > >
> > > https://godbolt.org/z/qTaDWP
> > >
> > char tu_data[0];/* data or error string */
> >
> > that seems an old stype variable length array
> > can you change it to char tu_data[] and see if it helps
> >
> > > Thanks!
> > >
> > > On Thu, Jul 18, 2019 at 11:02 PM Khem Raj  wrote:
> > > >
> > > > On Thu, Jul 18, 2019 at 12:46 PM Ricardo Ribalda Delgado
> > > >  wrote:
> > > > >
> > > > > When the code is compiled with  "-fstack-protector-strong
> > > > > -D_FORTIFY_SOURCE=2", everytime ftpfd is asked for a non existent 
> > > > > file,
> > > > > it crashes with the following error:
> > > > >
> > > > > *** buffer overflow detected ***:
> > > > > Aborted
> > > > >
> > > > > This seems to be a bug/feature of gcc. A bug has been open on their
> > > > > bugzilla, and also inetutils have been posted with the proposed patch.
> > > > >
> > > > > Without this patch, pxelinux fails to boot because it keeps asking the
> > > > > server for the pxelinux.cfg/00-01-02-03-04 and never jumps to 
> > > > > /default.
> > > > >
> > > > > Signed-off-by: Ricardo Ribalda Delgado 
> > > > > ---
> > > > >  .../inetutils/fix-buffer-fortify-tfpt.patch   | 25 
> > > > > +++
> > > > >  .../inetutils/inetutils_1.9.4.bb  |  1 +
> > > > >  2 files changed, 26 insertions(+)
> > > > >  create mode 100644 
> > > > > meta/recipes-connectivity/inetutils/inetutils/fix-buffer-fortify-tfpt.patch
> > > > >
> > > > > diff --git 
> > > > > a/meta/recipes-connectivity/inetutils/inetutils/fix-buffer-fortify-tfpt.patch
> > > > >  
> > > > > b/meta/recipes-connectivity/inetutils/inetutils/fix-buffer-fortify-tfpt.patch
> > > > > new file mode 100644
> > > > > index 00..a91913cb51
> > > > > --- /dev/null
> > > > > +++ 
> > > > > b/meta/recipes-connectivity/inetutils/inetutils/fix-buffer-fortify-tfpt.patch
> > > > > @@ -0,0 +1,25 @@
> > > > > +tftpd: Fix abort on error path
> > > > > +
> > > > > +When trying to fetch a non existent file, the app crashes with:
> > > > > +
> > > > > +*** buffer overflow detected ***:
> > > > > +Aborted
> > > > > +
> > > > > +
> > > > > +Upstream-Status: Submitted 
> > > > > [https://www.mail-archive.com/bug-inetutils@gnu.org/msg03036.html 
> > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91205]
> > > > > +Signed-off-by: Ricardo Ribalda Delgado 
> > > > > +diff --git a/src/tftpd.c b/src/tftpd.c
> > > > > +index 56002a0..144012f 100644
> > > > > +--- a/src/tftpd.c
> > > > >  b/src/tftpd.c
> > > > > +@@ -864,9 +864,8 @@ nak (int error)
> > > > > +   pe->e_msg = strerror (error - 100);
> > > > > +   tp->th_code = EUNDEF;   /* set 'undef' errorcode */
> > > > > + }
> > > > > +-  strcpy (tp->th_msg, pe->e_msg);
> > > > > +   length = strlen (pe->e_msg);
> > > >
> > > > I wonder if length calculation is a problem as well here, if so then
> > > > it would need
> > > > correcting because it used in code below as well.
> > > >
> > > > > +-  tp->th_msg[length] = '\0';
> > > > > ++  memcpy(tp->th_msg, pe->e_msg, length + 1);
> > > > > +   length += 5;
> > > > > +   if (sendto (peer, buf, length, 0, (struct sockaddr *) , 
>

Re: [OE-core] [PATCH] packagegroup-core-base-utils: Make it machine specific

2019-07-25 Thread Ricardo Ribalda Delgado
Sorry about that, I did not catch that on my builder.

I have sent a v2 of the patch, please let me know if you prefer
instead a "patch to fix the patch".

Thanks!

On Thu, Jul 25, 2019 at 6:15 AM Mittal, Anuj  wrote:
>
> This is causing errors:
>
> Parsing recipes...ERROR: /home/pokybuild/yocto-
> worker/multilib/build/meta/recipes-extended/packagegroups/packagegroup-
> core-base-utils.bb: Please ensure recipe /home/pokybuild/yocto-
> worker/multilib/build/meta/recipes-extended/packagegroups/packagegroup-
> core-base-utils.bb sets PACKAGE_ARCH before inherit packagegroup
> ERROR: /home/pokybuild/yocto-worker/multilib/build/meta/recipes-
> extended/packagegroups/packagegroup-core-base-utils.bb: Please ensure
> recipe /home/pokybuild/yocto-worker/multilib/build/meta/recipes-
> extended/packagegroups/packagegroup-core-base-utils.bb sets
> PACKAGE_ARCH before inherit packagegroup
> ERROR: /home/pokybuild/yocto-worker/multilib/build/meta/recipes-
> extended/packagegroups/packagegroup-core-base-utils.bb: Please ensure
> recipe /home/pokybuild/yocto-worker/multilib/build/meta/recipes-
> extended/packagegroups/packagegroup-core-base-utils.bb sets
> PACKAGE_ARCH before inherit packagegroup
> done.
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/44/builds/879/steps/8/logs/step6b
>
> Thanks,
>
> Anuj
>
> On Tue, 2019-07-23 at 14:37 +0200, Ricardo Ribalda Delgado wrote:
> > Recipe makes use of the variable MACHINE_FEATURES, which is machine
> > specific:
> >
> >   ${@bb.utils.contains("MACHINE_FEATURES", "keyboard", "kbd", "", d)}
> >
> > This patch avoids multiconfig errors such as:
> >
> > ERROR: mc:qt5222:packagegroup-core-base-utils-1.0-r0
> > do_package_qa_setscene: Error executing a python function in
> > exec_python_func() autogenerated:
> >
> > The stack trace of python calls that resulted in this
> > exception/failure was:
> > File: 'exec_python_func() autogenerated', lineno: 2, function:
> > 
> >  0001:
> >  *** 0002:do_package_qa_setscene(d)
> >  0003:
> > File: '/workdir/repo/poky/meta/classes/insane.bbclass', lineno: 1026,
> > function: do_package_qa_setscene
> >  1022:SSTATETASKS += "do_package_qa"
> >  1023:do_package_qa[sstate-inputdirs] = ""
> >  1024:do_package_qa[sstate-outputdirs] = ""
> >  1025:python do_package_qa_setscene () {
> >  *** 1026:sstate_setscene(d)
> >  1027:}
> >  1028:addtask do_package_qa_setscene
> >  1029:
> >  1030:python do_qa_staging() {
> >
> > Signed-off-by: Ricardo Ribalda Delgado 
> > ---
> >  .../packagegroups/packagegroup-core-base-utils.bb   | 2
> > ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/meta/recipes-extended/packagegroups/packagegroup-core-
> > base-utils.bb b/meta/recipes-extended/packagegroups/packagegroup-
> > core-base-utils.bb
> > index 611e0cafcc..935322cfe0 100644
> > --- a/meta/recipes-extended/packagegroups/packagegroup-core-base-
> > utils.bb
> > +++ b/meta/recipes-extended/packagegroups/packagegroup-core-base-
> > utils.bb
> > @@ -9,6 +9,8 @@ inherit packagegroup
> >
> >  VIRTUAL-RUNTIME_vim ?= "vim-tiny"
> >
> > +PACKAGE_ARCH = "${MACHINE_ARCH}"
> > +
> >  RDEPENDS_${PN} = "\
> >  base-passwd \
> >  bash \
> > --
> > 2.20.1
> >



-- 
Ricardo Ribalda
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH v2] packagegroup-core-base-utils: Make it machine specific

2019-07-25 Thread Ricardo Ribalda Delgado
Recipe makes use of the variable MACHINE_FEATURES, which is machine
specific:

  ${@bb.utils.contains("MACHINE_FEATURES", "keyboard", "kbd", "", d)}

This patch avoids multiconfig errors such as:

ERROR: mc:qt5222:packagegroup-core-base-utils-1.0-r0 do_package_qa_setscene: 
Error executing a python function in exec_python_func() autogenerated:

The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: 
 0001:
 *** 0002:do_package_qa_setscene(d)
 0003:
File: '/workdir/repo/poky/meta/classes/insane.bbclass', lineno: 1026, function: 
do_package_qa_setscene
 1022:SSTATETASKS += "do_package_qa"
 1023:do_package_qa[sstate-inputdirs] = ""
 1024:do_package_qa[sstate-outputdirs] = ""
 1025:python do_package_qa_setscene () {
 *** 1026:sstate_setscene(d)
 1027:}
 1028:addtask do_package_qa_setscene
 1029:
 1030:python do_qa_staging() {

Signed-off-by: Ricardo Ribalda Delgado 
Signed-off-by: Richard Purdie 
---

v2: Swap order of PACKAGE_ARCH = "${MACHINE_ARCH}" and  inherit packagegroup

This is causing errors:

Parsing recipes...ERROR: /home/pokybuild/yocto-
worker/multilib/build/meta/recipes-extended/packagegroups/packagegroup-
core-base-utils.bb: Please ensure recipe /home/pokybuild/yocto-
worker/multilib/build/meta/recipes-extended/packagegroups/packagegroup-
core-base-utils.bb sets PACKAGE_ARCH before inherit packagegroup
ERROR: /home/pokybuild/yocto-worker/multilib/build/meta/recipes-
extended/packagegroups/packagegroup-core-base-utils.bb: Please ensure
recipe /home/pokybuild/yocto-worker/multilib/build/meta/recipes-
extended/packagegroups/packagegroup-core-base-utils.bb sets
PACKAGE_ARCH before inherit packagegroup
ERROR: /home/pokybuild/yocto-worker/multilib/build/meta/recipes-
extended/packagegroups/packagegroup-core-base-utils.bb: Please ensure
recipe /home/pokybuild/yocto-worker/multilib/build/meta/recipes-
extended/packagegroups/packagegroup-core-base-utils.bb sets
PACKAGE_ARCH before inherit packagegroup
done.
https://autobuilder.yoctoproject.org/typhoon/#/builders/44/builds/879/steps/8/logs/step6b


 .../packagegroups/packagegroup-core-base-utils.bb   | 2 ++
 1 file changed, 2 insertions(+)

diff --git 
a/meta/recipes-extended/packagegroups/packagegroup-core-base-utils.bb 
b/meta/recipes-extended/packagegroups/packagegroup-core-base-utils.bb
index 611e0cafcc..18e227144a 100644
--- a/meta/recipes-extended/packagegroups/packagegroup-core-base-utils.bb
+++ b/meta/recipes-extended/packagegroups/packagegroup-core-base-utils.bb
@@ -5,6 +5,8 @@
 SUMMARY = "Full-featured set of base utils"
 DESCRIPTION = "Package group bringing in packages needed to provide much of 
the base utils type functionality found in busybox"
 
+PACKAGE_ARCH = "${MACHINE_ARCH}"
+
 inherit packagegroup
 
 VIRTUAL-RUNTIME_vim ?= "vim-tiny"
-- 
2.20.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [meta-oe][PATCH v2] fwts: Update to 19.06.00

2019-07-23 Thread Ricardo Ribalda Delgado
Update to latest release.

Since version 18.08.00, libbsd is a dependency:
https://wiki.ubuntu.com/FirmwareTestSuite/ReleaseNotes/18.08.00

Signed-off-by: Ricardo Ribalda Delgado 
---
 .../fwts/0001-Remove-Werror-from-build.patch  | 22 ++---
 ...t-logical-operand-warning-with-clang.patch | 84 ---
 .../fwts/{fwts_git.bb => fwts_19.06.00.bb}| 11 +--
 3 files changed, 15 insertions(+), 102 deletions(-)
 delete mode 100644 
meta-oe/recipes-test/fwts/fwts/0001-ignore-constant-logical-operand-warning-with-clang.patch
 rename meta-oe/recipes-test/fwts/{fwts_git.bb => fwts_19.06.00.bb} (83%)

diff --git a/meta-oe/recipes-test/fwts/fwts/0001-Remove-Werror-from-build.patch 
b/meta-oe/recipes-test/fwts/fwts/0001-Remove-Werror-from-build.patch
index 611ccc8fc..6795ba849 100644
--- a/meta-oe/recipes-test/fwts/fwts/0001-Remove-Werror-from-build.patch
+++ b/meta-oe/recipes-test/fwts/fwts/0001-Remove-Werror-from-build.patch
@@ -12,33 +12,33 @@ Upstream-Status: Pending
  3 files changed, 3 insertions(+), 3 deletions(-)
 
 diff --git a/src/Makefile.am b/src/Makefile.am
-index 4daa9e8f..873f23eb 100644
+index 62c9ba8..435ec23 100644
 --- a/src/Makefile.am
 +++ b/src/Makefile.am
 @@ -14,7 +14,7 @@ AM_CPPFLAGS = \
-   `pkg-config --silence-errors --cflags json` \
-   `pkg-config --silence-errors --cflags json-c` \
+   `pkg-config --silence-errors --cflags json` \
+   `pkg-config --silence-errors --cflags json-c`   \
-pthread `pkg-config --cflags glib-2.0 gio-2.0` \
--  -Wall -Werror -Wextra
-+  -Wall -Wextra
+-  -Wall -Werror -Wextra   \
++  -Wall -Wextra   \
+   -Wno-address-of-packed-member
  
  bin_PROGRAMS = fwts
- 
 diff --git a/src/lib/src/Makefile.am b/src/lib/src/Makefile.am
-index fa232451..082403a2 100644
+index 6bcf9f8..de89bf1 100644
 --- a/src/lib/src/Makefile.am
 +++ b/src/lib/src/Makefile.am
 @@ -24,7 +24,7 @@ AM_CPPFLAGS = \
`pkg-config --silence-errors --cflags json-c`   \
`pkg-config --cflags glib-2.0 gio-2.0`  \
-DDATAROOTDIR=\"$(datarootdir)\"\
--  -Wall -Werror -Wextra
-+  -Wall -Wextra
+-  -Wall -Werror -Wextra   \
++  -Wall -Wextra   \
+   -Wno-address-of-packed-member
  
  pkglib_LTLIBRARIES = libfwts.la
- 
 diff --git a/src/utilities/Makefile.am b/src/utilities/Makefile.am
-index aa37de55..4d5297cc 100644
+index 21f969e..82009a0 100644
 --- a/src/utilities/Makefile.am
 +++ b/src/utilities/Makefile.am
 @@ -16,7 +16,7 @@
diff --git 
a/meta-oe/recipes-test/fwts/fwts/0001-ignore-constant-logical-operand-warning-with-clang.patch
 
b/meta-oe/recipes-test/fwts/fwts/0001-ignore-constant-logical-operand-warning-with-clang.patch
deleted file mode 100644
index ae3665b4d..0
--- 
a/meta-oe/recipes-test/fwts/fwts/0001-ignore-constant-logical-operand-warning-with-clang.patch
+++ /dev/null
@@ -1,84 +0,0 @@
-From 5bd05ad8569880985ddf6d4c06ed927d388c297f Mon Sep 17 00:00:00 2001
-From: Khem Raj 
-Date: Wed, 19 Oct 2016 01:57:16 +
-Subject: [PATCH] ignore constant-logical-operand warning with clang
-
-Signed-off-by: Khem Raj 
-

- src/dmi/dmicheck/dmicheck.c| 3 +++
- src/lib/src/fwts_acpi_tables.c | 5 +
- src/uefi/uefirtauthvar/uefirtauthvar.c | 5 +
- 3 files changed, 13 insertions(+)
-
-diff --git a/src/dmi/dmicheck/dmicheck.c b/src/dmi/dmicheck/dmicheck.c
-index 3cca9db9..60fb758f 100644
 a/src/dmi/dmicheck/dmicheck.c
-+++ b/src/dmi/dmicheck/dmicheck.c
-@@ -211,6 +211,8 @@ static const char *uuid_patterns[] = {
-   "0A0A0A0A-0A0A-0A0A-0A0A-0A0A0A0A0A0A",
-   NULL,
- };
-+#pragma clang diagnostic push
-+#pragma clang diagnostic ignored "-Wunneeded-internal-declaration"
- 
- static const fwts_chassis_type_map fwts_dmi_chassis_type[] = {
-   { "Invalid",FWTS_SMBIOS_CHASSIS_INVALID },
-@@ -251,6 +253,7 @@ static const fwts_chassis_type_map fwts_dmi_chassis_type[] 
= {
-   { "Mini PC",FWTS_SMBIOS_CHASSIS_MINI_PC },
-   { "Stick PC",   FWTS_SMBIOS_CHASSIS_STICK_PC },
- };
-+#pragma clang diagnostic pop
- 
- /* Remapping table from buggy version numbers to correct values */
- static const fwts_dmi_version dmi_versions[] = {
-diff --git a/src/lib/src/fwts_acpi_tables.c b/src/lib/src/fwts_acpi_tables.c
-index c7ba59be..bdd224aa 100644
 a/src/lib/src/fwts_acpi_tables.c
-+++ b/src/lib/src/fwts_acpi_tables.c
-@@ -393,10 +393,14 @@ static int fwts_acpi_handle_fadt(
-   /* Determine FACS addr and load it.
-* Will ignore the missing FACS in the hardware-reduced mode.
-*/
-+#pragma clang diagnostic push
-+#pragma clang diagnostic ignored "-Waddress-of-packed-member"
-+
-   result = fwts_acpi_handle_fadt_tables(fw, fadt,
-   "FACS", "FIRMWARE_CTRL", "X_FIRMWARE_C

[OE-core] [meta-oe][PATCH] fwts: Update to 19.06.00

2019-07-23 Thread Ricardo Ribalda Delgado
Update to latest release.

Signed-off-by: Ricardo Ribalda Delgado 
---
 .../fwts/0001-Remove-Werror-from-build.patch  | 22 ++---
 ...t-logical-operand-warning-with-clang.patch | 84 ---
 .../fwts/{fwts_git.bb => fwts_19.06.00.bb}| 11 +--
 3 files changed, 15 insertions(+), 102 deletions(-)
 delete mode 100644 
meta-oe/recipes-test/fwts/fwts/0001-ignore-constant-logical-operand-warning-with-clang.patch
 rename meta-oe/recipes-test/fwts/{fwts_git.bb => fwts_19.06.00.bb} (83%)

diff --git a/meta-oe/recipes-test/fwts/fwts/0001-Remove-Werror-from-build.patch 
b/meta-oe/recipes-test/fwts/fwts/0001-Remove-Werror-from-build.patch
index 611ccc8fc..6795ba849 100644
--- a/meta-oe/recipes-test/fwts/fwts/0001-Remove-Werror-from-build.patch
+++ b/meta-oe/recipes-test/fwts/fwts/0001-Remove-Werror-from-build.patch
@@ -12,33 +12,33 @@ Upstream-Status: Pending
  3 files changed, 3 insertions(+), 3 deletions(-)
 
 diff --git a/src/Makefile.am b/src/Makefile.am
-index 4daa9e8f..873f23eb 100644
+index 62c9ba8..435ec23 100644
 --- a/src/Makefile.am
 +++ b/src/Makefile.am
 @@ -14,7 +14,7 @@ AM_CPPFLAGS = \
-   `pkg-config --silence-errors --cflags json` \
-   `pkg-config --silence-errors --cflags json-c` \
+   `pkg-config --silence-errors --cflags json` \
+   `pkg-config --silence-errors --cflags json-c`   \
-pthread `pkg-config --cflags glib-2.0 gio-2.0` \
--  -Wall -Werror -Wextra
-+  -Wall -Wextra
+-  -Wall -Werror -Wextra   \
++  -Wall -Wextra   \
+   -Wno-address-of-packed-member
  
  bin_PROGRAMS = fwts
- 
 diff --git a/src/lib/src/Makefile.am b/src/lib/src/Makefile.am
-index fa232451..082403a2 100644
+index 6bcf9f8..de89bf1 100644
 --- a/src/lib/src/Makefile.am
 +++ b/src/lib/src/Makefile.am
 @@ -24,7 +24,7 @@ AM_CPPFLAGS = \
`pkg-config --silence-errors --cflags json-c`   \
`pkg-config --cflags glib-2.0 gio-2.0`  \
-DDATAROOTDIR=\"$(datarootdir)\"\
--  -Wall -Werror -Wextra
-+  -Wall -Wextra
+-  -Wall -Werror -Wextra   \
++  -Wall -Wextra   \
+   -Wno-address-of-packed-member
  
  pkglib_LTLIBRARIES = libfwts.la
- 
 diff --git a/src/utilities/Makefile.am b/src/utilities/Makefile.am
-index aa37de55..4d5297cc 100644
+index 21f969e..82009a0 100644
 --- a/src/utilities/Makefile.am
 +++ b/src/utilities/Makefile.am
 @@ -16,7 +16,7 @@
diff --git 
a/meta-oe/recipes-test/fwts/fwts/0001-ignore-constant-logical-operand-warning-with-clang.patch
 
b/meta-oe/recipes-test/fwts/fwts/0001-ignore-constant-logical-operand-warning-with-clang.patch
deleted file mode 100644
index ae3665b4d..0
--- 
a/meta-oe/recipes-test/fwts/fwts/0001-ignore-constant-logical-operand-warning-with-clang.patch
+++ /dev/null
@@ -1,84 +0,0 @@
-From 5bd05ad8569880985ddf6d4c06ed927d388c297f Mon Sep 17 00:00:00 2001
-From: Khem Raj 
-Date: Wed, 19 Oct 2016 01:57:16 +
-Subject: [PATCH] ignore constant-logical-operand warning with clang
-
-Signed-off-by: Khem Raj 
-

- src/dmi/dmicheck/dmicheck.c| 3 +++
- src/lib/src/fwts_acpi_tables.c | 5 +
- src/uefi/uefirtauthvar/uefirtauthvar.c | 5 +
- 3 files changed, 13 insertions(+)
-
-diff --git a/src/dmi/dmicheck/dmicheck.c b/src/dmi/dmicheck/dmicheck.c
-index 3cca9db9..60fb758f 100644
 a/src/dmi/dmicheck/dmicheck.c
-+++ b/src/dmi/dmicheck/dmicheck.c
-@@ -211,6 +211,8 @@ static const char *uuid_patterns[] = {
-   "0A0A0A0A-0A0A-0A0A-0A0A-0A0A0A0A0A0A",
-   NULL,
- };
-+#pragma clang diagnostic push
-+#pragma clang diagnostic ignored "-Wunneeded-internal-declaration"
- 
- static const fwts_chassis_type_map fwts_dmi_chassis_type[] = {
-   { "Invalid",FWTS_SMBIOS_CHASSIS_INVALID },
-@@ -251,6 +253,7 @@ static const fwts_chassis_type_map fwts_dmi_chassis_type[] 
= {
-   { "Mini PC",FWTS_SMBIOS_CHASSIS_MINI_PC },
-   { "Stick PC",   FWTS_SMBIOS_CHASSIS_STICK_PC },
- };
-+#pragma clang diagnostic pop
- 
- /* Remapping table from buggy version numbers to correct values */
- static const fwts_dmi_version dmi_versions[] = {
-diff --git a/src/lib/src/fwts_acpi_tables.c b/src/lib/src/fwts_acpi_tables.c
-index c7ba59be..bdd224aa 100644
 a/src/lib/src/fwts_acpi_tables.c
-+++ b/src/lib/src/fwts_acpi_tables.c
-@@ -393,10 +393,14 @@ static int fwts_acpi_handle_fadt(
-   /* Determine FACS addr and load it.
-* Will ignore the missing FACS in the hardware-reduced mode.
-*/
-+#pragma clang diagnostic push
-+#pragma clang diagnostic ignored "-Waddress-of-packed-member"
-+
-   result = fwts_acpi_handle_fadt_tables(fw, fadt,
-   "FACS", "FIRMWARE_CTRL", "X_FIRMWARE_CTRL",
-   >firmware_control, >x_firmware_ctrl,
-

[OE-core] [PATCH] packagegroup-core-base-utils: Make it machine specific

2019-07-23 Thread Ricardo Ribalda Delgado
Recipe makes use of the variable MACHINE_FEATURES, which is machine
specific:

  ${@bb.utils.contains("MACHINE_FEATURES", "keyboard", "kbd", "", d)}

This patch avoids multiconfig errors such as:

ERROR: mc:qt5222:packagegroup-core-base-utils-1.0-r0 do_package_qa_setscene: 
Error executing a python function in exec_python_func() autogenerated:

The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: 
 0001:
 *** 0002:do_package_qa_setscene(d)
 0003:
File: '/workdir/repo/poky/meta/classes/insane.bbclass', lineno: 1026, function: 
do_package_qa_setscene
 1022:SSTATETASKS += "do_package_qa"
 1023:do_package_qa[sstate-inputdirs] = ""
 1024:do_package_qa[sstate-outputdirs] = ""
 1025:python do_package_qa_setscene () {
 *** 1026:sstate_setscene(d)
 1027:}
 1028:addtask do_package_qa_setscene
 1029:
 1030:python do_qa_staging() {

Signed-off-by: Ricardo Ribalda Delgado 
---
 .../packagegroups/packagegroup-core-base-utils.bb   | 2 ++
 1 file changed, 2 insertions(+)

diff --git 
a/meta/recipes-extended/packagegroups/packagegroup-core-base-utils.bb 
b/meta/recipes-extended/packagegroups/packagegroup-core-base-utils.bb
index 611e0cafcc..935322cfe0 100644
--- a/meta/recipes-extended/packagegroups/packagegroup-core-base-utils.bb
+++ b/meta/recipes-extended/packagegroups/packagegroup-core-base-utils.bb
@@ -9,6 +9,8 @@ inherit packagegroup
 
 VIRTUAL-RUNTIME_vim ?= "vim-tiny"
 
+PACKAGE_ARCH = "${MACHINE_ARCH}"
+
 RDEPENDS_${PN} = "\
 base-passwd \
 bash \
-- 
2.20.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] inetutils: Fix abort on invalid files

2019-07-19 Thread Ricardo Ribalda Delgado
Hi Khem

Indeed is due to that, but infortunately it is part of arpa/tftp.h .
So the propossed solutionI believe that it is simpler.

https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html

Also is what I have been suggested in #gcc


Thanks!

On Fri, Jul 19, 2019 at 12:39 AM Khem Raj  wrote:
>
> On Thu, Jul 18, 2019 at 2:10 PM Ricardo Ribalda Delgado
>  wrote:
> >
> > Hi Khem
> >
> > I think the issue is that __memcpy_chk wrongly assume that the target
> > size is 0. The origin size is calculated fine:
> >
> > https://godbolt.org/z/qTaDWP
> >
> char tu_data[0];/* data or error string */
>
> that seems an old stype variable length array
> can you change it to char tu_data[] and see if it helps
>
> > Thanks!
> >
> > On Thu, Jul 18, 2019 at 11:02 PM Khem Raj  wrote:
> > >
> > > On Thu, Jul 18, 2019 at 12:46 PM Ricardo Ribalda Delgado
> > >  wrote:
> > > >
> > > > When the code is compiled with  "-fstack-protector-strong
> > > > -D_FORTIFY_SOURCE=2", everytime ftpfd is asked for a non existent file,
> > > > it crashes with the following error:
> > > >
> > > > *** buffer overflow detected ***:
> > > > Aborted
> > > >
> > > > This seems to be a bug/feature of gcc. A bug has been open on their
> > > > bugzilla, and also inetutils have been posted with the proposed patch.
> > > >
> > > > Without this patch, pxelinux fails to boot because it keeps asking the
> > > > server for the pxelinux.cfg/00-01-02-03-04 and never jumps to /default.
> > > >
> > > > Signed-off-by: Ricardo Ribalda Delgado 
> > > > ---
> > > >  .../inetutils/fix-buffer-fortify-tfpt.patch   | 25 +++
> > > >  .../inetutils/inetutils_1.9.4.bb  |  1 +
> > > >  2 files changed, 26 insertions(+)
> > > >  create mode 100644 
> > > > meta/recipes-connectivity/inetutils/inetutils/fix-buffer-fortify-tfpt.patch
> > > >
> > > > diff --git 
> > > > a/meta/recipes-connectivity/inetutils/inetutils/fix-buffer-fortify-tfpt.patch
> > > >  
> > > > b/meta/recipes-connectivity/inetutils/inetutils/fix-buffer-fortify-tfpt.patch
> > > > new file mode 100644
> > > > index 00..a91913cb51
> > > > --- /dev/null
> > > > +++ 
> > > > b/meta/recipes-connectivity/inetutils/inetutils/fix-buffer-fortify-tfpt.patch
> > > > @@ -0,0 +1,25 @@
> > > > +tftpd: Fix abort on error path
> > > > +
> > > > +When trying to fetch a non existent file, the app crashes with:
> > > > +
> > > > +*** buffer overflow detected ***:
> > > > +Aborted
> > > > +
> > > > +
> > > > +Upstream-Status: Submitted 
> > > > [https://www.mail-archive.com/bug-inetutils@gnu.org/msg03036.html 
> > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91205]
> > > > +Signed-off-by: Ricardo Ribalda Delgado 
> > > > +diff --git a/src/tftpd.c b/src/tftpd.c
> > > > +index 56002a0..144012f 100644
> > > > +--- a/src/tftpd.c
> > > >  b/src/tftpd.c
> > > > +@@ -864,9 +864,8 @@ nak (int error)
> > > > +   pe->e_msg = strerror (error - 100);
> > > > +   tp->th_code = EUNDEF;   /* set 'undef' errorcode */
> > > > + }
> > > > +-  strcpy (tp->th_msg, pe->e_msg);
> > > > +   length = strlen (pe->e_msg);
> > >
> > > I wonder if length calculation is a problem as well here, if so then
> > > it would need
> > > correcting because it used in code below as well.
> > >
> > > > +-  tp->th_msg[length] = '\0';
> > > > ++  memcpy(tp->th_msg, pe->e_msg, length + 1);
> > > > +   length += 5;
> > > > +   if (sendto (peer, buf, length, 0, (struct sockaddr *) , 
> > > > fromlen) != length)
> > > > + syslog (LOG_ERR, "nak: %m\n");
> > > > diff --git a/meta/recipes-connectivity/inetutils/inetutils_1.9.4.bb 
> > > > b/meta/recipes-connectivity/inetutils/inetutils_1.9.4.bb
> > > > index ac2e017d8b..684fbe09e1 100644
> > > > --- a/meta/recipes-connectivity/inetutils/inetutils_1.9.4.bb
> > > > +++ b/meta/recipes-connectivity/inetutils/inetutils_1.9.4.bb
> > > > @@ -22,6 +22,7 @@ SRC_URI = 
> > > > "${GNU_MIRROR}/inetutils/inetutils-${PV}.tar.gz \
> > > > file://inetut

Re: [OE-core] [PATCH] inetutils: Fix abort on invalid files

2019-07-18 Thread Ricardo Ribalda Delgado
Hi Khem

I think the issue is that __memcpy_chk wrongly assume that the target
size is 0. The origin size is calculated fine:

https://godbolt.org/z/qTaDWP

Thanks!

On Thu, Jul 18, 2019 at 11:02 PM Khem Raj  wrote:
>
> On Thu, Jul 18, 2019 at 12:46 PM Ricardo Ribalda Delgado
>  wrote:
> >
> > When the code is compiled with  "-fstack-protector-strong
> > -D_FORTIFY_SOURCE=2", everytime ftpfd is asked for a non existent file,
> > it crashes with the following error:
> >
> > *** buffer overflow detected ***:
> > Aborted
> >
> > This seems to be a bug/feature of gcc. A bug has been open on their
> > bugzilla, and also inetutils have been posted with the proposed patch.
> >
> > Without this patch, pxelinux fails to boot because it keeps asking the
> > server for the pxelinux.cfg/00-01-02-03-04 and never jumps to /default.
> >
> > Signed-off-by: Ricardo Ribalda Delgado 
> > ---
> >  .../inetutils/fix-buffer-fortify-tfpt.patch   | 25 +++
> >  .../inetutils/inetutils_1.9.4.bb  |  1 +
> >  2 files changed, 26 insertions(+)
> >  create mode 100644 
> > meta/recipes-connectivity/inetutils/inetutils/fix-buffer-fortify-tfpt.patch
> >
> > diff --git 
> > a/meta/recipes-connectivity/inetutils/inetutils/fix-buffer-fortify-tfpt.patch
> >  
> > b/meta/recipes-connectivity/inetutils/inetutils/fix-buffer-fortify-tfpt.patch
> > new file mode 100644
> > index 00..a91913cb51
> > --- /dev/null
> > +++ 
> > b/meta/recipes-connectivity/inetutils/inetutils/fix-buffer-fortify-tfpt.patch
> > @@ -0,0 +1,25 @@
> > +tftpd: Fix abort on error path
> > +
> > +When trying to fetch a non existent file, the app crashes with:
> > +
> > +*** buffer overflow detected ***:
> > +Aborted
> > +
> > +
> > +Upstream-Status: Submitted 
> > [https://www.mail-archive.com/bug-inetutils@gnu.org/msg03036.html 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91205]
> > +Signed-off-by: Ricardo Ribalda Delgado 
> > +diff --git a/src/tftpd.c b/src/tftpd.c
> > +index 56002a0..144012f 100644
> > +--- a/src/tftpd.c
> >  b/src/tftpd.c
> > +@@ -864,9 +864,8 @@ nak (int error)
> > +   pe->e_msg = strerror (error - 100);
> > +   tp->th_code = EUNDEF;   /* set 'undef' errorcode */
> > + }
> > +-  strcpy (tp->th_msg, pe->e_msg);
> > +   length = strlen (pe->e_msg);
>
> I wonder if length calculation is a problem as well here, if so then
> it would need
> correcting because it used in code below as well.
>
> > +-  tp->th_msg[length] = '\0';
> > ++  memcpy(tp->th_msg, pe->e_msg, length + 1);
> > +   length += 5;
> > +   if (sendto (peer, buf, length, 0, (struct sockaddr *) , fromlen) 
> > != length)
> > + syslog (LOG_ERR, "nak: %m\n");
> > diff --git a/meta/recipes-connectivity/inetutils/inetutils_1.9.4.bb 
> > b/meta/recipes-connectivity/inetutils/inetutils_1.9.4.bb
> > index ac2e017d8b..684fbe09e1 100644
> > --- a/meta/recipes-connectivity/inetutils/inetutils_1.9.4.bb
> > +++ b/meta/recipes-connectivity/inetutils/inetutils_1.9.4.bb
> > @@ -22,6 +22,7 @@ SRC_URI = "${GNU_MIRROR}/inetutils/inetutils-${PV}.tar.gz 
> > \
> > file://inetutils-1.9-PATH_PROCNET_DEV.patch \
> > file://inetutils-only-check-pam_appl.h-when-pam-enabled.patch \
> > file://0001-rcp-fix-to-work-with-large-files.patch \
> > +   file://fix-buffer-fortify-tfpt.patch \
> >  "
> >
> >  SRC_URI[md5sum] = "04852c26c47cc8c6b825f2b74f191f52"
> > --
> > 2.20.1
> >
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core



-- 
Ricardo Ribalda
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] inetutils: Fix abort on invalid files

2019-07-18 Thread Ricardo Ribalda Delgado
When the code is compiled with  "-fstack-protector-strong
-D_FORTIFY_SOURCE=2", everytime ftpfd is asked for a non existent file,
it crashes with the following error:

*** buffer overflow detected ***:
Aborted

This seems to be a bug/feature of gcc. A bug has been open on their
bugzilla, and also inetutils have been posted with the proposed patch.

Without this patch, pxelinux fails to boot because it keeps asking the
server for the pxelinux.cfg/00-01-02-03-04 and never jumps to /default.

Signed-off-by: Ricardo Ribalda Delgado 
---
 .../inetutils/fix-buffer-fortify-tfpt.patch   | 25 +++
 .../inetutils/inetutils_1.9.4.bb  |  1 +
 2 files changed, 26 insertions(+)
 create mode 100644 
meta/recipes-connectivity/inetutils/inetutils/fix-buffer-fortify-tfpt.patch

diff --git 
a/meta/recipes-connectivity/inetutils/inetutils/fix-buffer-fortify-tfpt.patch 
b/meta/recipes-connectivity/inetutils/inetutils/fix-buffer-fortify-tfpt.patch
new file mode 100644
index 00..a91913cb51
--- /dev/null
+++ 
b/meta/recipes-connectivity/inetutils/inetutils/fix-buffer-fortify-tfpt.patch
@@ -0,0 +1,25 @@
+tftpd: Fix abort on error path
+
+When trying to fetch a non existent file, the app crashes with:
+
+*** buffer overflow detected ***: 
+Aborted
+
+
+Upstream-Status: Submitted 
[https://www.mail-archive.com/bug-inetutils@gnu.org/msg03036.html 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91205]
+Signed-off-by: Ricardo Ribalda Delgado 
+diff --git a/src/tftpd.c b/src/tftpd.c
+index 56002a0..144012f 100644
+--- a/src/tftpd.c
 b/src/tftpd.c
+@@ -864,9 +864,8 @@ nak (int error)
+   pe->e_msg = strerror (error - 100);
+   tp->th_code = EUNDEF;   /* set 'undef' errorcode */
+ }
+-  strcpy (tp->th_msg, pe->e_msg);
+   length = strlen (pe->e_msg);
+-  tp->th_msg[length] = '\0';
++  memcpy(tp->th_msg, pe->e_msg, length + 1);
+   length += 5;
+   if (sendto (peer, buf, length, 0, (struct sockaddr *) , fromlen) != 
length)
+ syslog (LOG_ERR, "nak: %m\n");
diff --git a/meta/recipes-connectivity/inetutils/inetutils_1.9.4.bb 
b/meta/recipes-connectivity/inetutils/inetutils_1.9.4.bb
index ac2e017d8b..684fbe09e1 100644
--- a/meta/recipes-connectivity/inetutils/inetutils_1.9.4.bb
+++ b/meta/recipes-connectivity/inetutils/inetutils_1.9.4.bb
@@ -22,6 +22,7 @@ SRC_URI = "${GNU_MIRROR}/inetutils/inetutils-${PV}.tar.gz \
file://inetutils-1.9-PATH_PROCNET_DEV.patch \
file://inetutils-only-check-pam_appl.h-when-pam-enabled.patch \
file://0001-rcp-fix-to-work-with-large-files.patch \
+   file://fix-buffer-fortify-tfpt.patch \
 "
 
 SRC_URI[md5sum] = "04852c26c47cc8c6b825f2b74f191f52"
-- 
2.20.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] wic: Fix (again) partition files UIDs on multi rootfs images

2019-07-18 Thread Ricardo Ribalda Delgado
Commit 450335ba5e73a375eb9932b4c4cf37979640dbfc copies the pseudo
database to the working directory in order to have ownership information
when the filesystem is generated.

Unfortunately this does not work anymore. The filenames on the database
are absolute and there is no information about the new directory.

Instead of fixing the database, we could redo a bit the way we patch the
fstab file. Now I am saving the old contents of fstab, modifying the
file and then reverting the changes on exit.

This is faster than the previous approach, although it can cause
indeterminism if the application is killed before finishing.

Signed-off-by: Ricardo Ribalda Delgado 
---
 scripts/lib/wic/plugins/imager/direct.py | 37 
 1 file changed, 12 insertions(+), 25 deletions(-)

diff --git a/scripts/lib/wic/plugins/imager/direct.py 
b/scripts/lib/wic/plugins/imager/direct.py
index 67addeff3e..91fc5e70f6 100644
--- a/scripts/lib/wic/plugins/imager/direct.py
+++ b/scripts/lib/wic/plugins/imager/direct.py
@@ -49,7 +49,6 @@ class DirectPlugin(ImagerPlugin):
 
 # parse possible 'rootfs=name' items
 self.rootfs_dir = dict(rdir.split('=') for rdir in rootfs_dir.split(' 
'))
-self.replaced_rootfs_paths = {}
 self.bootimg_dir = bootimg_dir
 self.kernel_dir = kernel_dir
 self.native_sysroot = native_sysroot
@@ -59,6 +58,7 @@ class DirectPlugin(ImagerPlugin):
 self.compressor = options.compressor
 self.bmap = options.bmap
 self.no_fstab_update = options.no_fstab_update
+self.original_fstab = None
 
 self.name = "%s-%s" % (os.path.splitext(os.path.basename(wks_file))[0],
strftime("%Y%m%d%H%M"))
@@ -104,24 +104,13 @@ class DirectPlugin(ImagerPlugin):
 
 with open(fstab_path) as fstab:
 fstab_lines = fstab.readlines()
+self.original_fstab = fstab_lines.copy()
 
 if self._update_fstab(fstab_lines, self.parts):
-# copy rootfs dir to workdir to update fstab
-# as rootfs can be used by other tasks and can't be modified
-new_pseudo = os.path.realpath(os.path.join(self.workdir, "pseudo"))
-from_dir = os.path.join(os.path.join(image_rootfs, ".."), "pseudo")
-from_dir = os.path.realpath(from_dir)
-copyhardlinktree(from_dir, new_pseudo)
-new_rootfs = os.path.realpath(os.path.join(self.workdir, 
"rootfs_copy"))
-copyhardlinktree(image_rootfs, new_rootfs)
-fstab_path = os.path.join(new_rootfs, 'etc/fstab')
-
-os.unlink(fstab_path)
-
 with open(fstab_path, "w") as fstab:
 fstab.writelines(fstab_lines)
-
-return new_rootfs
+else:
+self.original_fstab = None
 
 def _update_fstab(self, fstab_lines, parts):
 """Assume partition order same as in wks"""
@@ -170,14 +159,8 @@ class DirectPlugin(ImagerPlugin):
 filesystems from the artifacts directly and combine them into
 a partitioned image.
 """
-if self.no_fstab_update:
-new_rootfs = None
-else:
-new_rootfs = self._write_fstab(self.rootfs_dir.get("ROOTFS_DIR"))
-if new_rootfs:
-# rootfs was copied to update fstab
-self.replaced_rootfs_paths[new_rootfs] = 
self.rootfs_dir['ROOTFS_DIR']
-self.rootfs_dir['ROOTFS_DIR'] = new_rootfs
+if not self.no_fstab_update:
+self._write_fstab(self.rootfs_dir.get("ROOTFS_DIR"))
 
 for part in self.parts:
 # get rootfs size from bitbake variable if it's not set in .ks file
@@ -253,8 +236,6 @@ class DirectPlugin(ImagerPlugin):
 else:
 suffix = '["%s"]:' % (part.mountpoint or part.label)
 rootdir = part.rootfs_dir
-if rootdir in self.replaced_rootfs_paths:
-rootdir = self.replaced_rootfs_paths[rootdir]
 msg += '  ROOTFS_DIR%s%s\n' % (suffix.ljust(20), rootdir)
 
 msg += '  BOOTIMG_DIR:  %s\n' % self.bootimg_dir
@@ -292,6 +273,12 @@ class DirectPlugin(ImagerPlugin):
 if os.path.isfile(path):
 shutil.move(path, os.path.join(self.outdir, fname))
 
+#Restore original fstab
+if self.original_fstab:
+fstab_path = self.rootfs_dir.get("ROOTFS_DIR") + "/etc/fstab"
+with open(fstab_path, "w") as fstab:
+fstab.writelines(self.original_fstab)
+
 # remove work directory
 shutil.rmtree(self.workdir, ignore_errors=True)
 
-- 
2.20.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH v2] systemd: Fix interface bring-up on kernels >= 5.2

2019-07-15 Thread Ricardo Ribalda Delgado
With kernels >=5.2  systemd-networkd is unable to bring up the link.

eth0: Could not bring up interface: Invalid argument

This is already reported upstream and fixed on master:

https://github.com/systemd/systemd/issues/12784

They recommend Debian to backport two patches.

Signed-off-by: Ricardo Ribalda Delgado 
---
 .../systemd/0001-networkd-fix-link-up.patch   | 66 +
 .../0002-network-do-not-send-ipv6.patch   | 96 +++
 meta/recipes-core/systemd/systemd_242.bb  |  2 +
 3 files changed, 164 insertions(+)
 create mode 100644 
meta/recipes-core/systemd/systemd/0001-networkd-fix-link-up.patch
 create mode 100644 
meta/recipes-core/systemd/systemd/0002-network-do-not-send-ipv6.patch

diff --git a/meta/recipes-core/systemd/systemd/0001-networkd-fix-link-up.patch 
b/meta/recipes-core/systemd/systemd/0001-networkd-fix-link-up.patch
new file mode 100644
index 00..4c7a0a33a3
--- /dev/null
+++ b/meta/recipes-core/systemd/systemd/0001-networkd-fix-link-up.patch
@@ -0,0 +1,66 @@
+From 6bd76d2d4ff130decd3aa13e0c2dbfd56ff8d7b7 Mon Sep 17 00:00:00 2001
+From: Susant Sahani 
+Date: Thu, 9 May 2019 07:35:35 +0530
+Subject: [PATCH] networkd: fix link_up() (#12505)
+
+Fillup IFLA_INET6_ADDR_GEN_MODE while we do link_up.
+
+Fixes the following error:
+```
+dummy-test: Could not bring up interface: Invalid argument
+```
+
+After reading the kernel code when we do a link up
+```
+net/core/rtnetlink.c
+IFLA_AF_SPEC
+ af_ops->set_link_af(dev, af);
+  inet6_set_link_af
+   if (tb[IFLA_INET6_ADDR_GEN_MODE])
+ Here it looks for IFLA_INET6_ADDR_GEN_MODE
+```
+Since link up we didn't filling up that it's failing.
+
+Closes #12504.
+
+Signed-off-by: Ricardo Ribalda Delgado 
+
+Upstream-Status: Backport 
[https://github.com/systemd/systemd/commit/4eb086a38712ea98faf41e075b84555b11b54362.patch]
+
+---
+ src/network/networkd-link.c | 15 +++
+ 1 file changed, 15 insertions(+)
+
+diff --git a/src/network/networkd-link.c b/src/network/networkd-link.c
+index e466b96792..042496173c 100644
+--- a/src/network/networkd-link.c
 b/src/network/networkd-link.c
+@@ -2034,6 +2034,8 @@ static int link_up(Link *link) {
+ }
+ 
+ if (link_ipv6_enabled(link)) {
++uint8_t ipv6ll_mode;
++
+ r = sd_netlink_message_open_container(req, IFLA_AF_SPEC);
+ if (r < 0)
+ return log_link_error_errno(link, r, "Could not open 
IFLA_AF_SPEC container: %m");
+@@ -2049,6 +2051,19 @@ static int link_up(Link *link) {
+ return log_link_error_errno(link, r, "Could 
not append IFLA_INET6_TOKEN: %m");
+ }
+ 
++if (!link_ipv6ll_enabled(link))
++ipv6ll_mode = IN6_ADDR_GEN_MODE_NONE;
++else if (sysctl_read_ip_property(AF_INET6, link->ifname, 
"stable_secret", NULL) < 0)
++/* The file may not exist. And event if it exists, 
when stable_secret is unset,
++ * reading the file fails with EIO. */
++ipv6ll_mode = IN6_ADDR_GEN_MODE_EUI64;
++else
++ipv6ll_mode = IN6_ADDR_GEN_MODE_STABLE_PRIVACY;
++
++r = sd_netlink_message_append_u8(req, 
IFLA_INET6_ADDR_GEN_MODE, ipv6ll_mode);
++if (r < 0)
++return log_link_error_errno(link, r, "Could not 
append IFLA_INET6_ADDR_GEN_MODE: %m");
++
+ r = sd_netlink_message_close_container(req);
+ if (r < 0)
+ return log_link_error_errno(link, r, "Could not close 
AF_INET6 container: %m");
diff --git 
a/meta/recipes-core/systemd/systemd/0002-network-do-not-send-ipv6.patch 
b/meta/recipes-core/systemd/systemd/0002-network-do-not-send-ipv6.patch
new file mode 100644
index 00..2565314876
--- /dev/null
+++ b/meta/recipes-core/systemd/systemd/0002-network-do-not-send-ipv6.patch
@@ -0,0 +1,96 @@
+From b5c4eb818101127a606849e822937b15b8497c75 Mon Sep 17 00:00:00 2001
+From: Yu Watanabe 
+Date: Thu, 9 May 2019 14:39:46 +0900
+Subject: [PATCH] network: do not send ipv6 token to kernel
+
+We disabled kernel RA support. Then, we should not send
+IFLA_INET6_TOKEN.
+Thus, we do not need to send IFLA_INET6_ADDR_GEN_MODE twice.
+
+Follow-up for 0e2fdb83bb5e22047e0c7cc058b415d0e93f02cf and
+4eb086a38712ea98faf41e075b84555b11b54362.
+
+Signed-off-by: Ricardo Ribalda Delgado 
+
+Upstream-Status: Backport 
[https://github.com/systemd/systemd/commit/9f6e82e6eb3b6e73d66d00d1d6eee60691fb702f]
+
+---
+ src/network/networkd-link.c | 51 +
+ 1 file changed, 6 insertions(+), 45 deletions(-)
+
+diff --git a/src/network/networkd-link.c b/src/network/networkd-link.c
+index 042496173c..c49dba33da 100644
+--- a/src/network/networkd-link.c
 b/src/network/networkd-link.c
+@@ -1940,6 +1940,9 @

[OE-core] [PATCH] nfs-mountd: Add missing dependency on systemd service

2019-07-15 Thread Ricardo Ribalda Delgado
As described on: https://www.spinics.net/lists/linux-nfs/msg62022.html

mountd requires rpcbind, otherwise it can can fail to start, which can
lead to nfsroot not booting.

Upstream: 
http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=907426b00bdcd69d9a56ac1870990e8ae8c6fe9f

Signed-off-by: Ricardo Ribalda Delgado 
---
 meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-mountd.service | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-mountd.service 
b/meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-mountd.service
index 27ea58d366..3c3a8022ce 100644
--- a/meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-mountd.service
+++ b/meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-mountd.service
@@ -1,6 +1,7 @@
 [Unit]
 Description=NFS Mount Daemon
 DefaultDependencies=no
+After=rpcbind.socket
 Requires=proc-fs-nfsd.mount
 After=proc-fs-nfsd.mount
 After=network.target local-fs.target
-- 
2.20.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] systemd: Fix interface bring-up on kernels >= 5.2

2019-07-09 Thread Ricardo Ribalda Delgado
Hi Alex

That would also be ok. Is this already on a released version or is
only on the "master" branch?



On Tue, Jul 9, 2019 at 1:12 PM Alex Kiernan  wrote:
>
> On Tue, Jul 9, 2019 at 9:43 AM Ricardo Ribalda Delgado
>  wrote:
> >
> > With kernels >=5.2  systemd-networkd is unable to bring up the link.
> >
> > eth0: Could not bring up interface: Invalid argument
> >
> > This is already reported upstream and fixed on master:
> >
> > https://github.com/systemd/systemd/issues/12784
> >
> > They recommend Debian to backport two patches.
> >
> > Signed-off-by: Ricardo Ribalda Delgado 
> > ---
>
> Could we just move the SRCREV to the top of systemd-stable, which
> includes a change that looks a lot like this problem, but isn't the
> exact same change?
>
> --
> Alex Kiernan



-- 
Ricardo Ribalda
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] systemd: Fix interface bring-up on kernels >= 5.2

2019-07-09 Thread Ricardo Ribalda Delgado
With kernels >=5.2  systemd-networkd is unable to bring up the link.

eth0: Could not bring up interface: Invalid argument

This is already reported upstream and fixed on master:

https://github.com/systemd/systemd/issues/12784

They recommend Debian to backport two patches.

Signed-off-by: Ricardo Ribalda Delgado 
---
 .../systemd/0001-networkd-fix-link-up.patch   | 66 +
 .../0002-network-do-not-send-ipv6.patch   | 96 +++
 meta/recipes-core/systemd/systemd_242.bb  |  2 +
 3 files changed, 164 insertions(+)
 create mode 100644 
meta/recipes-core/systemd/systemd/0001-networkd-fix-link-up.patch
 create mode 100644 
meta/recipes-core/systemd/systemd/0002-network-do-not-send-ipv6.patch

diff --git a/meta/recipes-core/systemd/systemd/0001-networkd-fix-link-up.patch 
b/meta/recipes-core/systemd/systemd/0001-networkd-fix-link-up.patch
new file mode 100644
index 00..7a3b3f172d
--- /dev/null
+++ b/meta/recipes-core/systemd/systemd/0001-networkd-fix-link-up.patch
@@ -0,0 +1,66 @@
+From 6bd76d2d4ff130decd3aa13e0c2dbfd56ff8d7b7 Mon Sep 17 00:00:00 2001
+From: Susant Sahani 
+Date: Thu, 9 May 2019 07:35:35 +0530
+Subject: [PATCH] networkd: fix link_up() (#12505)
+
+Fillup IFLA_INET6_ADDR_GEN_MODE while we do link_up.
+
+Fixes the following error:
+```
+dummy-test: Could not bring up interface: Invalid argument
+```
+
+After reading the kernel code when we do a link up
+```
+net/core/rtnetlink.c
+IFLA_AF_SPEC
+ af_ops->set_link_af(dev, af);
+  inet6_set_link_af
+   if (tb[IFLA_INET6_ADDR_GEN_MODE])
+ Here it looks for IFLA_INET6_ADDR_GEN_MODE
+```
+Since link up we didn't filling up that it's failing.
+
+Closes #12504.
+
+Signed-off-by: Ricardo Ribalda Delgado 
+
+Upstream-Status: backport 
https://github.com/systemd/systemd/commit/4eb086a38712ea98faf41e075b84555b11b54362.patch
+
+---
+ src/network/networkd-link.c | 15 +++
+ 1 file changed, 15 insertions(+)
+
+diff --git a/src/network/networkd-link.c b/src/network/networkd-link.c
+index e466b96792..042496173c 100644
+--- a/src/network/networkd-link.c
 b/src/network/networkd-link.c
+@@ -2034,6 +2034,8 @@ static int link_up(Link *link) {
+ }
+ 
+ if (link_ipv6_enabled(link)) {
++uint8_t ipv6ll_mode;
++
+ r = sd_netlink_message_open_container(req, IFLA_AF_SPEC);
+ if (r < 0)
+ return log_link_error_errno(link, r, "Could not open 
IFLA_AF_SPEC container: %m");
+@@ -2049,6 +2051,19 @@ static int link_up(Link *link) {
+ return log_link_error_errno(link, r, "Could 
not append IFLA_INET6_TOKEN: %m");
+ }
+ 
++if (!link_ipv6ll_enabled(link))
++ipv6ll_mode = IN6_ADDR_GEN_MODE_NONE;
++else if (sysctl_read_ip_property(AF_INET6, link->ifname, 
"stable_secret", NULL) < 0)
++/* The file may not exist. And event if it exists, 
when stable_secret is unset,
++ * reading the file fails with EIO. */
++ipv6ll_mode = IN6_ADDR_GEN_MODE_EUI64;
++else
++ipv6ll_mode = IN6_ADDR_GEN_MODE_STABLE_PRIVACY;
++
++r = sd_netlink_message_append_u8(req, 
IFLA_INET6_ADDR_GEN_MODE, ipv6ll_mode);
++if (r < 0)
++return log_link_error_errno(link, r, "Could not 
append IFLA_INET6_ADDR_GEN_MODE: %m");
++
+ r = sd_netlink_message_close_container(req);
+ if (r < 0)
+ return log_link_error_errno(link, r, "Could not close 
AF_INET6 container: %m");
diff --git 
a/meta/recipes-core/systemd/systemd/0002-network-do-not-send-ipv6.patch 
b/meta/recipes-core/systemd/systemd/0002-network-do-not-send-ipv6.patch
new file mode 100644
index 00..6e6ace4c5f
--- /dev/null
+++ b/meta/recipes-core/systemd/systemd/0002-network-do-not-send-ipv6.patch
@@ -0,0 +1,96 @@
+From b5c4eb818101127a606849e822937b15b8497c75 Mon Sep 17 00:00:00 2001
+From: Yu Watanabe 
+Date: Thu, 9 May 2019 14:39:46 +0900
+Subject: [PATCH] network: do not send ipv6 token to kernel
+
+We disabled kernel RA support. Then, we should not send
+IFLA_INET6_TOKEN.
+Thus, we do not need to send IFLA_INET6_ADDR_GEN_MODE twice.
+
+Follow-up for 0e2fdb83bb5e22047e0c7cc058b415d0e93f02cf and
+4eb086a38712ea98faf41e075b84555b11b54362.
+
+Signed-off-by: Ricardo Ribalda Delgado 
+
+Upstream-Status: backport 
https://github.com/systemd/systemd/commit/9f6e82e6eb3b6e73d66d00d1d6eee60691fb702f
+
+---
+ src/network/networkd-link.c | 51 +
+ 1 file changed, 6 insertions(+), 45 deletions(-)
+
+diff --git a/src/network/networkd-link.c b/src/network/networkd-link.c
+index 042496173c..c49dba33da 100644
+--- a/src/network/networkd-link.c
 b/src/network/networkd-link.c
+@@ -1940,6 +1940,9 @

Re: [OE-core] [PATCH v2] systemd-bootconf: Make is machine specific

2019-07-09 Thread Ricardo Ribalda Delgado
Hi Richard

Something else that I need to fix on this patch?

Thanks!

On Wed, Jul 3, 2019 at 6:33 PM Ricardo Ribalda Delgado
 wrote:
>
> Recipe makes use of the variable APPEND:
>
> do_configure[vardeps] += "APPEND"
>
> APPEND is usually linked to a to a machine and not to a
> cpu architecture, as it describe things like the location
> of the main serial port or tty.
>
> Therefore the recipe should be MACHINE_ARCH.
>
> This patch avoids multiconfig errors such as:
>
> | NOTE: Direct dependencies are 
> ['multiconfig:qt5022:/workdir/repo/poky/meta/recipes-core/glibc/glibc_2.29.bb:do_populate_sysroot',
>  
> 'multiconfig:qt5022:virtual:native:/workdir/repo/poky/meta/recipes-devtools/pseudo/pseudo_git.bb:do_populate_sysroot',
>  
> 'multiconfig:qt5022:/workdir/repo/poky/meta/recipes-devtools/quilt/quilt-native_0.65.bb:do_populate_sysroot',
>  
> 'multiconfig:qt5022:/workdir/repo/poky/meta/recipes-devtools/gcc/gcc-cross_8.3.bb:do_populate_sysroot',
>  
> 'multiconfig:qt5022:/workdir/repo/poky/meta/recipes-devtools/gcc/gcc-runtime_8.3.bb:do_populate_sysroot']
> | NOTE: Installed into sysroot: []
> | NOTE: Skipping as already exists in sysroot: ['glibc', 'pseudo-native', 
> 'quilt-native', 'gcc-cross-x86_64', 'gcc-runtime', 'libgcc', 
> 'linux-libc-headers', 'libtool-native', 'texinfo-dummy-native', 
> 'libmpc-native', 'flex-native', 'automake-native', 'zlib-native', 
> 'mpfr-native', 'gmp-native', 'binutils-cross-x86_64', 'xz-native', 
> 'autoconf-native', 'gnu-config-native', 'gettext-minimal-native', 'm4-native']
> | DEBUG: Python function extend_recipe_sysroot finished
> | DEBUG: Executing shell function do_install
> | install: cannot stat 'loader.conf': No such file or directory
> | WARNING: exit code 1 from a shell command.
> | ERROR: Function failed: do_install (log file is located at 
> /workdir/build/tmp/work/bobcat-poky-linux/systemd-bootconf/1.00-r0/temp/log.do_install.737)
> NOTE: recipe systemd-bootconf-1.00-r0: task do_install: Failed
> ERROR: Task 
> (multiconfig:qt5022:/workdir/repo/poky/meta/recipes-core/systemd/systemd-bootconf_1.00.bb:do_install)
>  failed with exit code '1'
>
> Signed-off-by: Ricardo Ribalda Delgado 
> ---
>  meta/recipes-core/systemd/systemd-bootconf_1.00.bb | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/meta/recipes-core/systemd/systemd-bootconf_1.00.bb 
> b/meta/recipes-core/systemd/systemd-bootconf_1.00.bb
> index e9c2466456..d13b8c518f 100644
> --- a/meta/recipes-core/systemd/systemd-bootconf_1.00.bb
> +++ b/meta/recipes-core/systemd/systemd-bootconf_1.00.bb
> @@ -3,6 +3,7 @@ LIC_FILES_CHKSUM = 
> "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384
>  SUMMARY = "Basic systemd-boot configuration files"
>
>  RPROVIDES_${PN} += "virtual/systemd-bootconf"
> +PACKAGE_ARCH = "${MACHINE_ARCH}"
>
>  inherit systemd-boot-cfg
>
> --
> 2.20.1
>


-- 
Ricardo Ribalda
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH v2] systemd-bootconf: Make is machine specific

2019-07-03 Thread Ricardo Ribalda Delgado
Recipe makes use of the variable APPEND:

do_configure[vardeps] += "APPEND"

APPEND is usually linked to a to a machine and not to a
cpu architecture, as it describe things like the location
of the main serial port or tty.

Therefore the recipe should be MACHINE_ARCH.

This patch avoids multiconfig errors such as:

| NOTE: Direct dependencies are 
['multiconfig:qt5022:/workdir/repo/poky/meta/recipes-core/glibc/glibc_2.29.bb:do_populate_sysroot',
 
'multiconfig:qt5022:virtual:native:/workdir/repo/poky/meta/recipes-devtools/pseudo/pseudo_git.bb:do_populate_sysroot',
 
'multiconfig:qt5022:/workdir/repo/poky/meta/recipes-devtools/quilt/quilt-native_0.65.bb:do_populate_sysroot',
 
'multiconfig:qt5022:/workdir/repo/poky/meta/recipes-devtools/gcc/gcc-cross_8.3.bb:do_populate_sysroot',
 
'multiconfig:qt5022:/workdir/repo/poky/meta/recipes-devtools/gcc/gcc-runtime_8.3.bb:do_populate_sysroot']
| NOTE: Installed into sysroot: []
| NOTE: Skipping as already exists in sysroot: ['glibc', 'pseudo-native', 
'quilt-native', 'gcc-cross-x86_64', 'gcc-runtime', 'libgcc', 
'linux-libc-headers', 'libtool-native', 'texinfo-dummy-native', 
'libmpc-native', 'flex-native', 'automake-native', 'zlib-native', 
'mpfr-native', 'gmp-native', 'binutils-cross-x86_64', 'xz-native', 
'autoconf-native', 'gnu-config-native', 'gettext-minimal-native', 'm4-native']
| DEBUG: Python function extend_recipe_sysroot finished
| DEBUG: Executing shell function do_install
| install: cannot stat 'loader.conf': No such file or directory
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_install (log file is located at 
/workdir/build/tmp/work/bobcat-poky-linux/systemd-bootconf/1.00-r0/temp/log.do_install.737)
NOTE: recipe systemd-bootconf-1.00-r0: task do_install: Failed
ERROR: Task 
(multiconfig:qt5022:/workdir/repo/poky/meta/recipes-core/systemd/systemd-bootconf_1.00.bb:do_install)
 failed with exit code '1'

Signed-off-by: Ricardo Ribalda Delgado 
---
 meta/recipes-core/systemd/systemd-bootconf_1.00.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-core/systemd/systemd-bootconf_1.00.bb 
b/meta/recipes-core/systemd/systemd-bootconf_1.00.bb
index e9c2466456..d13b8c518f 100644
--- a/meta/recipes-core/systemd/systemd-bootconf_1.00.bb
+++ b/meta/recipes-core/systemd/systemd-bootconf_1.00.bb
@@ -3,6 +3,7 @@ LIC_FILES_CHKSUM = 
"file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384
 SUMMARY = "Basic systemd-boot configuration files"
 
 RPROVIDES_${PN} += "virtual/systemd-bootconf"
+PACKAGE_ARCH = "${MACHINE_ARCH}"
 
 inherit systemd-boot-cfg
 
-- 
2.20.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] systemd-bootconf: Make is machine specific

2019-07-03 Thread Ricardo Ribalda Delgado
Ping?

On Tue, 25 Jun 2019, 09:14 Ricardo Ribalda Delgado, 
wrote:

> APPEND is usually attached to a machine. This patch avoids multiconfig
> errors such as:
>
> | NOTE: Direct dependencies are
> ['multiconfig:qt5022:/workdir/repo/poky/meta/recipes-core/glibc/glibc_2.29.bb:do_populate_sysroot',
> 'multiconfig:qt5022:virtual:native:/workdir/repo/poky/meta/recipes-devtools/pseudo/pseudo_git.bb:do_populate_sysroot',
> 'multiconfig:qt5022:/workdir/repo/poky/meta/recipes-devtools/quilt/quilt-native_0.65.bb:do_populate_sysroot',
> 'multiconfig:qt5022:/workdir/repo/poky/meta/recipes-devtools/gcc/
> gcc-cross_8.3.bb:do_populate_sysroot',
> 'multiconfig:qt5022:/workdir/repo/poky/meta/recipes-devtools/gcc/gcc-runtime_8.3.bb:
> do_populate_sysroot']
> | NOTE: Installed into sysroot: []
> | NOTE: Skipping as already exists in sysroot: ['glibc', 'pseudo-native',
> 'quilt-native', 'gcc-cross-x86_64', 'gcc-runtime', 'libgcc',
> 'linux-libc-headers', 'libtool-native', 'texinfo-dummy-native',
> 'libmpc-native', 'flex-native', 'automake-native', 'zlib-native',
> 'mpfr-native', 'gmp-native', 'binutils-cross-x86_64', 'xz-native',
> 'autoconf-native', 'gnu-config-native', 'gettext-minimal-native',
> 'm4-native']
> | DEBUG: Python function extend_recipe_sysroot finished
> | DEBUG: Executing shell function do_install
> | install: cannot stat 'loader.conf': No such file or directory
> | WARNING: exit code 1 from a shell command.
> | ERROR: Function failed: do_install (log file is located at
> /workdir/build/tmp/work/bobcat-poky-linux/systemd-bootconf/1.00-r0/temp/log.do_install.737)
> NOTE: recipe systemd-bootconf-1.00-r0: task do_install: Failed
> ERROR: Task
> (multiconfig:qt5022:/workdir/repo/poky/meta/recipes-core/systemd/systemd-bootconf_1.00.bb:do_install)
> failed with exit code '1'
>
> Signed-off-by: Ricardo Ribalda Delgado 
> ---
>  meta/recipes-core/systemd/systemd-bootconf_1.00.bb | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/meta/recipes-core/systemd/systemd-bootconf_1.00.bb
> b/meta/recipes-core/systemd/systemd-bootconf_1.00.bb
> index e9c2466456..d13b8c518f 100644
> --- a/meta/recipes-core/systemd/systemd-bootconf_1.00.bb
> +++ b/meta/recipes-core/systemd/systemd-bootconf_1.00.bb
> @@ -3,6 +3,7 @@ LIC_FILES_CHKSUM =
> "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384
>  SUMMARY = "Basic systemd-boot configuration files"
>
>  RPROVIDES_${PN} += "virtual/systemd-bootconf"
> +PACKAGE_ARCH = "${MACHINE_ARCH}"
>
>  inherit systemd-boot-cfg
>
> --
> 2.20.1
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] systemd-bootconf: Make is machine specific

2019-06-25 Thread Ricardo Ribalda Delgado
APPEND is usually attached to a machine. This patch avoids multiconfig
errors such as:

| NOTE: Direct dependencies are 
['multiconfig:qt5022:/workdir/repo/poky/meta/recipes-core/glibc/glibc_2.29.bb:do_populate_sysroot',
 
'multiconfig:qt5022:virtual:native:/workdir/repo/poky/meta/recipes-devtools/pseudo/pseudo_git.bb:do_populate_sysroot',
 
'multiconfig:qt5022:/workdir/repo/poky/meta/recipes-devtools/quilt/quilt-native_0.65.bb:do_populate_sysroot',
 
'multiconfig:qt5022:/workdir/repo/poky/meta/recipes-devtools/gcc/gcc-cross_8.3.bb:do_populate_sysroot',
 
'multiconfig:qt5022:/workdir/repo/poky/meta/recipes-devtools/gcc/gcc-runtime_8.3.bb:do_populate_sysroot']
| NOTE: Installed into sysroot: []
| NOTE: Skipping as already exists in sysroot: ['glibc', 'pseudo-native', 
'quilt-native', 'gcc-cross-x86_64', 'gcc-runtime', 'libgcc', 
'linux-libc-headers', 'libtool-native', 'texinfo-dummy-native', 
'libmpc-native', 'flex-native', 'automake-native', 'zlib-native', 
'mpfr-native', 'gmp-native', 'binutils-cross-x86_64', 'xz-native', 
'autoconf-native', 'gnu-config-native', 'gettext-minimal-native', 'm4-native']
| DEBUG: Python function extend_recipe_sysroot finished
| DEBUG: Executing shell function do_install
| install: cannot stat 'loader.conf': No such file or directory
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_install (log file is located at 
/workdir/build/tmp/work/bobcat-poky-linux/systemd-bootconf/1.00-r0/temp/log.do_install.737)
NOTE: recipe systemd-bootconf-1.00-r0: task do_install: Failed
ERROR: Task 
(multiconfig:qt5022:/workdir/repo/poky/meta/recipes-core/systemd/systemd-bootconf_1.00.bb:do_install)
 failed with exit code '1'

Signed-off-by: Ricardo Ribalda Delgado 
---
 meta/recipes-core/systemd/systemd-bootconf_1.00.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-core/systemd/systemd-bootconf_1.00.bb 
b/meta/recipes-core/systemd/systemd-bootconf_1.00.bb
index e9c2466456..d13b8c518f 100644
--- a/meta/recipes-core/systemd/systemd-bootconf_1.00.bb
+++ b/meta/recipes-core/systemd/systemd-bootconf_1.00.bb
@@ -3,6 +3,7 @@ LIC_FILES_CHKSUM = 
"file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384
 SUMMARY = "Basic systemd-boot configuration files"
 
 RPROVIDES_${PN} += "virtual/systemd-bootconf"
+PACKAGE_ARCH = "${MACHINE_ARCH}"
 
 inherit systemd-boot-cfg
 
-- 
2.20.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] go: avoid host contamination by GOCACHE

2019-06-21 Thread Ricardo Ribalda Delgado
By default GOCACHE is set to $HOME/.cache.

Fixes:
ERROR: go-cross-dbfp4-1.12.1-r0 do_compile: Function failed: do_compile (log 
file is located at 
/workdir/build/tmp/work/x86_64-linux/go-cross-dbfp4/1.12.1-r0/temp/log.do_compile.8120)
ERROR: Logfile of failure stored in: 
/workdir/build/tmp/work/x86_64-linux/go-cross-dbfp4/1.12.1-r0/temp/log.do_compile.8120
Log data follows:
| DEBUG: Executing shell function do_compile
| Building Go cmd/dist using 
/workdir/build/tmp/work/x86_64-linux/go-cross-dbfp4/1.12.1-r0/recipe-sysroot-native/usr/lib/go.
| failed to initialize build cache at /home/pokyuser/.cache/go-build: mkdir 
/home/pokyuser/.cache: permission denied
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_compile (log file is located at 
/workdir/build/tmp/work/x86_64-linux/go-cross-dbfp4/1.12.1-r0/temp/log.do_compile.8120)
ERROR: Task 
(/workdir/repo/poky/meta/recipes-devtools/go/go-cross_1.12.bb:do_compile) 
failed with exit code '1'
NOTE: Tasks Summary: Attempted 23 tasks of which 16 didn't need to be rerun and 
1 failed.

Signed-off-by: Ricardo Ribalda Delgado 
---
 meta/classes/go.bbclass | 1 +
 meta/recipes-devtools/go/go-cross.inc   | 1 +
 meta/recipes-devtools/go/go-runtime.inc | 1 +
 meta/recipes-devtools/go/go-target.inc  | 1 +
 4 files changed, 4 insertions(+)

diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
index b6d9372c56..e05a5c641c 100644
--- a/meta/classes/go.bbclass
+++ b/meta/classes/go.bbclass
@@ -7,6 +7,7 @@ GOROOT_class-nativesdk = "${STAGING_DIR_TARGET}${libdir}/go"
 GOROOT = "${STAGING_LIBDIR}/go"
 export GOROOT
 export GOROOT_FINAL = "${libdir}/go"
+export GOCACHE = "${B}/.cache"
 
 export GOARCH = "${TARGET_GOARCH}"
 export GOOS = "${TARGET_GOOS}"
diff --git a/meta/recipes-devtools/go/go-cross.inc 
b/meta/recipes-devtools/go/go-cross.inc
index 29ce7f6e84..3d344a74d3 100644
--- a/meta/recipes-devtools/go/go-cross.inc
+++ b/meta/recipes-devtools/go/go-cross.inc
@@ -14,6 +14,7 @@ export GO386 = "${TARGET_GO386}"
 export GOMIPS = "${TARGET_GOMIPS}"
 export GOROOT_BOOTSTRAP = "${STAGING_LIBDIR_NATIVE}/go"
 export GOROOT_FINAL = "${libdir}/go"
+export GOCACHE = "${B}/.cache"
 CC = "${@d.getVar('BUILD_CC').strip()}"
 
 do_configure[noexec] = "1"
diff --git a/meta/recipes-devtools/go/go-runtime.inc 
b/meta/recipes-devtools/go/go-runtime.inc
index c219aa3789..e282195619 100644
--- a/meta/recipes-devtools/go/go-runtime.inc
+++ b/meta/recipes-devtools/go/go-runtime.inc
@@ -15,6 +15,7 @@ export CGO_CFLAGS = "${CFLAGS}"
 export CGO_CPPFLAGS = "${CPPFLAGS}"
 export CGO_CXXFLAGS = "${CXXFLAGS}"
 export CGO_LDFLAGS = "${LDFLAGS}"
+export GOCACHE = "${B}/.cache"
 
 GO_EXTLDFLAGS ?= "${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS} ${LDFLAGS}"
 GO_SHLIB_LDFLAGS ?= '-ldflags="--linkmode=external -extldflags 
'${GO_EXTLDFLAGS}'"'
diff --git a/meta/recipes-devtools/go/go-target.inc 
b/meta/recipes-devtools/go/go-target.inc
index 379f87b498..91efd3e977 100644
--- a/meta/recipes-devtools/go/go-target.inc
+++ b/meta/recipes-devtools/go/go-target.inc
@@ -10,6 +10,7 @@ export GO386 = "${TARGET_GO386}"
 export GOMIPS = "${TARGET_GOMIPS}"
 export GOROOT_BOOTSTRAP = "${STAGING_LIBDIR_NATIVE}/go"
 export GOROOT_FINAL = "${libdir}/go"
+export GOCACHE = "${B}/.cache"
 GO_LDFLAGS = ""
 GO_LDFLAGS_class-nativesdk = "-linkmode external"
 export GO_LDFLAGS
-- 
2.20.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH v2] dpkg: Use less as pager

2019-06-19 Thread Ricardo Ribalda Delgado
Debian traditionaly uses /usr/bin/pager as the system pager, which is a
link to the user preferred pager. This is a Debianism.

Without this patch:

root@qt5122:~# dpkg -l
sh: pager: command not found
dpkg-query: error: showing package list on pager subprocess returned error exit 
status 127

Signed-off-by: Ricardo Ribalda Delgado 
---
 meta/recipes-devtools/dpkg/dpkg/pager.patch | 21 +
 meta/recipes-devtools/dpkg/dpkg_1.19.4.bb   |  1 +
 2 files changed, 22 insertions(+)
 create mode 100644 meta/recipes-devtools/dpkg/dpkg/pager.patch

diff --git a/meta/recipes-devtools/dpkg/dpkg/pager.patch 
b/meta/recipes-devtools/dpkg/dpkg/pager.patch
new file mode 100644
index 00..e56b9d28af
--- /dev/null
+++ b/meta/recipes-devtools/dpkg/dpkg/pager.patch
@@ -0,0 +1,21 @@
+pager: Use less instead of pager
+
+pager is a Debianism. Istead use directly pager.
+
+Upstream-Status: Inappropriate [OE-Core integration specific]
+
+Suggested-by: Burton, Ross 
+Signed-off-by: Ricardo Ribalda 
+diff --git a/lib/dpkg/dpkg.h b/lib/dpkg/dpkg.h
+index 2bb067a..6cbce80 100644
+--- a/lib/dpkg/dpkg.h
 b/lib/dpkg/dpkg.h
+@@ -95,7 +95,7 @@ DPKG_BEGIN_DECLS
+ #define MAXUPDATES 250
+ 
+ #define DEFAULTSHELL"sh"
+-#define DEFAULTPAGER"pager"
++#define DEFAULTPAGER"less"
+ 
+ #define MD5HASHLEN   32
+ #define MAXTRIGDIRECTIVE 256
diff --git a/meta/recipes-devtools/dpkg/dpkg_1.19.4.bb 
b/meta/recipes-devtools/dpkg/dpkg_1.19.4.bb
index 77fbfb5c91..b83868fec0 100644
--- a/meta/recipes-devtools/dpkg/dpkg_1.19.4.bb
+++ b/meta/recipes-devtools/dpkg/dpkg_1.19.4.bb
@@ -12,6 +12,7 @@ SRC_URI = "${DEBIAN_MIRROR}/main/d/${BPN}/${BPN}_${PV}.tar.xz 
\
file://0006-add-musleabi-to-known-target-tripets.patch \

file://0007-dpkg-deb-build.c-Remove-usage-of-clamp-mtime-in-tar.patch \
file://0001-dpkg-Support-muslx32-build.patch \
+   file://pager.patch \
"
 SRC_URI_append_class-native = " \
 file://tweak-options-require-tar-1.27.patch \
-- 
2.20.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] dpkg: Use less as pager

2019-06-19 Thread Ricardo Ribalda Delgado
Debian traditionaly uses /usr/bin/pager as the system pager, which is a
link to the user preferred pager. This is a Debianism.

Without this patch:

root@qt5122:~# dpkg -l
sh: pager: command not found
dpkg-query: error: showing package list on pager subprocess returned error exit 
status 127

Signed-off-by: Ricardo Ribalda Delgado 
---
 meta/recipes-devtools/dpkg/dpkg.inc |  2 +-
 meta/recipes-devtools/dpkg/dpkg/pager.patch | 21 +
 meta/recipes-devtools/dpkg/dpkg_1.19.4.bb   |  1 +
 3 files changed, 23 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-devtools/dpkg/dpkg/pager.patch

diff --git a/meta/recipes-devtools/dpkg/dpkg.inc 
b/meta/recipes-devtools/dpkg/dpkg.inc
index fee7a75814..21ebf2d926 100644
--- a/meta/recipes-devtools/dpkg/dpkg.inc
+++ b/meta/recipes-devtools/dpkg/dpkg.inc
@@ -4,7 +4,7 @@ SECTION = "base"
 
 DEPENDS = "zlib bzip2 perl ncurses"
 DEPENDS_class-native = "bzip2-replacement-native zlib-native 
virtual/update-alternatives-native gettext-native perl-native"
-RDEPENDS_${PN} = "${VIRTUAL-RUNTIME_update-alternatives} perl"
+RDEPENDS_${PN} = "${VIRTUAL-RUNTIME_update-alternatives} perl less"
 RDEPENDS_${PN}_class-native = ""
 
 UPSTREAM_CHECK_URI = "${DEBIAN_MIRROR}/main/d/dpkg/"
diff --git a/meta/recipes-devtools/dpkg/dpkg/pager.patch 
b/meta/recipes-devtools/dpkg/dpkg/pager.patch
new file mode 100644
index 00..e56b9d28af
--- /dev/null
+++ b/meta/recipes-devtools/dpkg/dpkg/pager.patch
@@ -0,0 +1,21 @@
+pager: Use less instead of pager
+
+pager is a Debianism. Istead use directly pager.
+
+Upstream-Status: Inappropriate [OE-Core integration specific]
+
+Suggested-by: Burton, Ross 
+Signed-off-by: Ricardo Ribalda 
+diff --git a/lib/dpkg/dpkg.h b/lib/dpkg/dpkg.h
+index 2bb067a..6cbce80 100644
+--- a/lib/dpkg/dpkg.h
 b/lib/dpkg/dpkg.h
+@@ -95,7 +95,7 @@ DPKG_BEGIN_DECLS
+ #define MAXUPDATES 250
+ 
+ #define DEFAULTSHELL"sh"
+-#define DEFAULTPAGER"pager"
++#define DEFAULTPAGER"less"
+ 
+ #define MD5HASHLEN   32
+ #define MAXTRIGDIRECTIVE 256
diff --git a/meta/recipes-devtools/dpkg/dpkg_1.19.4.bb 
b/meta/recipes-devtools/dpkg/dpkg_1.19.4.bb
index 77fbfb5c91..b83868fec0 100644
--- a/meta/recipes-devtools/dpkg/dpkg_1.19.4.bb
+++ b/meta/recipes-devtools/dpkg/dpkg_1.19.4.bb
@@ -12,6 +12,7 @@ SRC_URI = "${DEBIAN_MIRROR}/main/d/${BPN}/${BPN}_${PV}.tar.xz 
\
file://0006-add-musleabi-to-known-target-tripets.patch \

file://0007-dpkg-deb-build.c-Remove-usage-of-clamp-mtime-in-tar.patch \
file://0001-dpkg-Support-muslx32-build.patch \
+   file://pager.patch \
"
 SRC_URI_append_class-native = " \
 file://tweak-options-require-tar-1.27.patch \
-- 
2.20.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH 1/2] less: Create symlink for pager

2019-06-19 Thread Ricardo Ribalda Delgado
Hi Ross

I am ok with that.

But looking forward it is definitely more difficult to maintain that
patch on future dpkg versions. Will prepare the patch and then you
decide :P

Thanks!

On Wed, Jun 19, 2019 at 11:55 AM Burton, Ross  wrote:
>
> dpkg may, but that's because dpkg is the Debian package manager and it
> follows Debian traditions.  /usr/bin/pager is a Debianism: I suggest
> we just patch it to use 'less'.
>
> Ross
>
> On Wed, 19 Jun 2019 at 10:47, Ricardo Ribalda Delgado
>  wrote:
> >
> > Some system tools (like dpkg) expects a binary called pager when they
> > run on a interactive console.
> >
> > This patch addes this symlink via alternative, so other packages can
> > also provide this symlink.
> >
> > Signed-off-by: Ricardo Ribalda Delgado 
> > ---
> >  meta/recipes-extended/less/less_550.bb | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-extended/less/less_550.bb 
> > b/meta/recipes-extended/less/less_550.bb
> > index bb1618f1eb..8f59bd6087 100644
> > --- a/meta/recipes-extended/less/less_550.bb
> > +++ b/meta/recipes-extended/less/less_550.bb
> > @@ -24,6 +24,7 @@ LIC_FILES_CHKSUM = 
> > "file://COPYING;md5=d32239bcb673463ab874e80d47fae504 \
> >  file://LICENSE;md5=ba01d0cab7f62f7f2204c7780ff6a87d \
> >  "
> >  DEPENDS = "ncurses"
> > +RPROVIDES_${PN} = "pager"
> >
> >  SRC_URI = "http://www.greenwoodsoftware.com/${BPN}/${BPN}-${PV}.tar.gz \
> >   "
> > @@ -39,5 +40,6 @@ do_install () {
> >  oe_runmake 'bindir=${D}${bindir}' 'mandir=${D}${mandir}' install
> >  }
> >
> > -ALTERNATIVE_${PN} = "less"
> > +ALTERNATIVE_${PN} = "less pager"
> >  ALTERNATIVE_PRIORITY = "100"
> > +ALTERNATIVE_TARGET[pager] = "/usr/bin/less.less"
> > --
> > 2.20.1
> >
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



-- 
Ricardo Ribalda
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH 1/2] less: Create symlink for pager

2019-06-19 Thread Ricardo Ribalda Delgado
Some system tools (like dpkg) expects a binary called pager when they
run on a interactive console.

This patch addes this symlink via alternative, so other packages can
also provide this symlink.

Signed-off-by: Ricardo Ribalda Delgado 
---
 meta/recipes-extended/less/less_550.bb | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-extended/less/less_550.bb 
b/meta/recipes-extended/less/less_550.bb
index bb1618f1eb..8f59bd6087 100644
--- a/meta/recipes-extended/less/less_550.bb
+++ b/meta/recipes-extended/less/less_550.bb
@@ -24,6 +24,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=d32239bcb673463ab874e80d47fae504 \
 file://LICENSE;md5=ba01d0cab7f62f7f2204c7780ff6a87d \
 "
 DEPENDS = "ncurses"
+RPROVIDES_${PN} = "pager"
 
 SRC_URI = "http://www.greenwoodsoftware.com/${BPN}/${BPN}-${PV}.tar.gz \
  "
@@ -39,5 +40,6 @@ do_install () {
 oe_runmake 'bindir=${D}${bindir}' 'mandir=${D}${mandir}' install
 }
 
-ALTERNATIVE_${PN} = "less"
+ALTERNATIVE_${PN} = "less pager"
 ALTERNATIVE_PRIORITY = "100"
+ALTERNATIVE_TARGET[pager] = "/usr/bin/less.less"
-- 
2.20.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] python3: python3: Fix build error x86->x86

2019-06-19 Thread Ricardo Ribalda Delgado
When building x86->x86 the system will try to execute .so and related items
from the default PYTHONPATH.  This will fail if the target CPU contains
instructions that the host CPU does not have, add CROSSPYTHONPATH
into PYTHONPATH so we can prepend the list to find correct libs.

Fixes:

Illegal instruction (core dumped)
Makefile:625: recipe for target 'sharedmods' failed
make: *** [sharedmods] Error 132
make: *** Waiting for unfinished jobs

Signed-off-by: Ricardo Ribalda Delgado 
---
 .../python/python3/crosspythonpath.patch  | 25 +++
 meta/recipes-devtools/python/python3_3.7.3.bb |  2 ++
 2 files changed, 27 insertions(+)
 create mode 100644 meta/recipes-devtools/python/python3/crosspythonpath.patch

diff --git a/meta/recipes-devtools/python/python3/crosspythonpath.patch 
b/meta/recipes-devtools/python/python3/crosspythonpath.patch
new file mode 100644
index 00..d789ab57d4
--- /dev/null
+++ b/meta/recipes-devtools/python/python3/crosspythonpath.patch
@@ -0,0 +1,25 @@
+configure.ac: add CROSSPYTHONPATH into PYTHONPATH for PYTHON_FOR_BUILD
+
+When building x86->x86 the system will try to execute .so and related items
+from the default PYTHONPATH.  This will fail if the target CPU contains
+instructions that the host CPU does not have, add CROSSPYTHONPATH
+into PYTHONPATH so we can prepend the list to find correct libs.
+
+Upstream-Status: Inappropriate [OE-Core integration specific]
+
+Credits-to: Mark Hatle 
+Credits-to: Jackie Huang 
+Signed-off-by: Ricardo Ribalda 
+diff --git a/configure.ac b/configure.ac
+index 4ab19a6..7036a53 100644
+--- a/configure.ac
 b/configure.ac
+@@ -76,7 +76,7 @@ if test "$cross_compiling" = yes; then
+   AC_MSG_ERROR([python$PACKAGE_VERSION interpreter not found])
+   fi
+ AC_MSG_RESULT($interp)
+-  PYTHON_FOR_BUILD='_PYTHON_PROJECT_BASE=$(abs_builddir) 
_PYTHON_HOST_PLATFORM=$(_PYTHON_HOST_PLATFORM) PYTHONPATH=$(shell test -f 
pybuilddir.txt && echo $(abs_builddir)/`cat pybuilddir.txt`:)$(srcdir)/Lib 
_PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata_$(ABIFLAGS)_$(MACHDEP)_$(MULTIARCH) 
'$interp
++  PYTHON_FOR_BUILD='_PYTHON_PROJECT_BASE=$(abs_builddir) 
_PYTHON_HOST_PLATFORM=$(_PYTHON_HOST_PLATFORM) 
PYTHONPATH=$(CROSSPYTHONPATH):$(shell test -f pybuilddir.txt && echo 
$(abs_builddir)/`cat pybuilddir.txt`:)$(srcdir)/Lib 
_PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata_$(ABIFLAGS)_$(MACHDEP)_$(MULTIARCH) 
'$interp
+ fi
+ elif test "$cross_compiling" = maybe; then
+ AC_MSG_ERROR([Cross compiling required --host=HOST-TUPLE and 
--build=ARCH])
diff --git a/meta/recipes-devtools/python/python3_3.7.3.bb 
b/meta/recipes-devtools/python/python3_3.7.3.bb
index 832ef1b3c3..2444296142 100644
--- a/meta/recipes-devtools/python/python3_3.7.3.bb
+++ b/meta/recipes-devtools/python/python3_3.7.3.bb
@@ -24,6 +24,7 @@ SRC_URI = 
"http://www.python.org/ftp/python/${PV}/Python-${PV}.tar.xz \

file://0001-Lib-sysconfig.py-fix-another-place-where-lib-is-hard.patch \

file://0001-Makefile-fix-Issue36464-parallel-build-race-problem.patch \
   
file://0001-bpo-36852-proper-detection-of-mips-architecture-for-.patch \
+  file://crosspythonpath.patch \
"
 
 SRC_URI_append_class-native = " \
@@ -65,6 +66,7 @@ DEPENDS_append_class-nativesdk = " python3-native"
 EXTRA_OECONF = " --without-ensurepip --enable-shared"
 EXTRA_OECONF_append_class-native = " --bindir=${bindir}/${PN}"
 
+export 
CROSSPYTHONPATH="${STAGING_LIBDIR_NATIVE}/python${PYTHON_MAJMIN}/lib-dynload/"
 
 EXTRANATIVEPATH += "python3-native"
 
-- 
2.20.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH 2/2] dpkg: add missing running dependency

2019-06-19 Thread Ricardo Ribalda Delgado
Without this patch:

root@qt5122:~# dpkg -l
sh: pager: command not found
dpkg-query: error: showing package list on pager subprocess returned error exit 
status 127

Signed-off-by: Ricardo Ribalda Delgado 
---
 meta/recipes-devtools/dpkg/dpkg.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/dpkg/dpkg.inc 
b/meta/recipes-devtools/dpkg/dpkg.inc
index fee7a75814..ec9eadd21a 100644
--- a/meta/recipes-devtools/dpkg/dpkg.inc
+++ b/meta/recipes-devtools/dpkg/dpkg.inc
@@ -4,7 +4,7 @@ SECTION = "base"
 
 DEPENDS = "zlib bzip2 perl ncurses"
 DEPENDS_class-native = "bzip2-replacement-native zlib-native 
virtual/update-alternatives-native gettext-native perl-native"
-RDEPENDS_${PN} = "${VIRTUAL-RUNTIME_update-alternatives} perl"
+RDEPENDS_${PN} = "${VIRTUAL-RUNTIME_update-alternatives} perl pager"
 RDEPENDS_${PN}_class-native = ""
 
 UPSTREAM_CHECK_URI = "${DEBIAN_MIRROR}/main/d/dpkg/"
-- 
2.20.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] rootfs: Fix dependency for every dpkg run

2019-06-19 Thread Ricardo Ribalda Delgado
Avoid getting a warning on do_rootfs.

Fixes:

NOTE: Installing the following packages: libgdk-pixbuf-2.0-locale-en-gb 
glibc-locale-en-gb libatspi-locale-en-gb gstreamer1.0-locale-en-gb 
gtk+3-locale-en libatk-1.0-locale-en-gb gtk+3-locale-en-gb 
gstreamer1.0-plugins-good-locale-en-gb gstreamer1.0-plugins-base-locale-en-gb 
gstreamer1.0-plugins-bad-locale-en-gb libglib-2.0-locale-en-gb 
avahi-locale-en-gb vte-locale-en-gb xkeyboard-config-locale-en-gb
WARNING: Unable to install packages. Command 
'/workdir/build/tmp/work/qt5122-poky-linux/bottlecam-image/1.0-r0/recipe-sysroot-native/usr/bin/apt-get
  install --force-yes --allow-unauthenticated libgdk-pixbuf-2.0-locale-en-gb 
glibc-locale-en-gb libatspi-locale-en-gb gstreamer1.0-locale-en-gb 
gtk+3-locale-en libatk-1.0-locale-en-gb gtk+3-locale-en-gb 
gstreamer1.0-plugins-good-locale-en-gb gstreamer1.0-plugins-base-locale-en-gb 
gstreamer1.0-plugins-bad-locale-en-gb libglib-2.0-locale-en-gb 
avahi-locale-en-gb vte-locale-en-gb xkeyboard-config-locale-en-gb' returned 100:
Reading package lists...
Building dependency tree...
Reading state information...

Signed-off-by: Ricardo Ribalda Delgado 
---
 meta/lib/oe/rootfs.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/lib/oe/rootfs.py b/meta/lib/oe/rootfs.py
index 9358f562c8..c62fa5f54a 100644
--- a/meta/lib/oe/rootfs.py
+++ b/meta/lib/oe/rootfs.py
@@ -647,6 +647,7 @@ class DpkgRootfs(DpkgOpkgRootfs):
 if pkg_type in pkgs_to_install:
 self.pm.install(pkgs_to_install[pkg_type],
 [False, True][pkg_type == 
Manifest.PKG_TYPE_ATTEMPT_ONLY])
+self.pm.fix_broken_dependencies()
 
 if self.progress_reporter:
 # Don't support attemptonly, so skip that
-- 
2.20.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] meson: Fix native patch to python3

2019-06-19 Thread Ricardo Ribalda Delgado
Fixes:

  File 
"/workdir/build/tmp/work/dbfp4-poky-linux/qv4l2/1.17.0+gitAUTOINC+95f39aae48-r0/recipe-sysroot-native/usr/lib/python3.7/site-packages/mesonbuild/dependencies/base.py",
 line 574, in _call_pkgbin
cache[(self.pkgbin, targs, fenv)] = self._call_pkgbin_real(args, env, 
use_native)
  File 
"/workdir/build/tmp/work/dbfp4-poky-linux/qv4l2/1.17.0+gitAUTOINC+95f39aae48-r0/recipe-sysroot-native/usr/lib/python3.7/site-packages/mesonbuild/dependencies/base.py",
 line 556, in _call_pkgbin_real
cmd = self.pkgbin.get_command() + "-native" + args
TypeError: can only concatenate list (not "str") to list

Signed-off-by: Ricardo Ribalda Delgado 
---
 meta/recipes-devtools/meson/meson/0003-native_bindir.patch | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/meson/meson/0003-native_bindir.patch 
b/meta/recipes-devtools/meson/meson/0003-native_bindir.patch
index da477454cb..2b22531dd0 100644
--- a/meta/recipes-devtools/meson/meson/0003-native_bindir.patch
+++ b/meta/recipes-devtools/meson/meson/0003-native_bindir.patch
@@ -51,7 +51,7 @@ index 6d3678f..90fdb80 100644
 -cmd = self.pkgbin.get_command() + args
 +def _call_pkgbin_real(self, args, env, use_native=False):
 +if use_native:
-+cmd = self.pkgbin.get_command() + "-native" + args
++cmd = [self.pkgbin.get_command()[0] + "-native"] + args
 +else:
 +cmd = self.pkgbin.get_command() + args
  p, out = Popen_safe(cmd, env=env)[0:2]
-- 
2.20.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] Two recipes providing the same .so... How it should not be done :)

2019-03-05 Thread Ricardo Ribalda Delgado
Yes, but I want to do it slightly differently

Instead of a big package with all the blobs I want to split it in
something that mimics the current package structure.
Also I want to run it inside a multiconfig setup.

Once everything works I want to upstream it to mesa-tegra.

On Tue, Mar 5, 2019 at 12:17 PM Burton, Ross  wrote:
>
> Isn't this something that https://github.com/madisongh/meta-tegra already 
> does?
>
> Ross
>
> On Tue, 5 Mar 2019 at 11:10, Ricardo Ribalda Delgado
>  wrote:
> >
> > This is my approach (which is not more than a horrible hack)
> >
> > DESCRIPTION = "Tegra replacements for mesa libraries"
> > require recipes-bsp/tegra-binaries/tegra-glvnd.inc
> > RDEPENDS_libgl-mesa = "tegra-lib-common libegl-mesa libxcb-glx
> > libxxf86vm libxdamage libxcb-xfixes"
> > RDEPENDS_libegl-mesa = "zlib libxcb-xfixes libxcb-present libdrm
> > libxshmfence libxcb-sync libglapi expat libxcb-dri2 libgbm libxcb-dri3
> > libx11 libx11-xcb"
> > RDEPENDS_libgles2-mesa = "libdrm libglapi"
> > RDEPENDS_libgles1-mesa = "libdrm libglapi"
> > RPROVIDES_libgl-mesa += "gl-proprietary libgl"
> > RPROVIDES_libegl-mesa += "libegl"
> > RPROVIDES_libgles2-mesa += "libgles2"
> > RPROVIDES_libgles1-mesa += "libgles1"
> > PV = "${L4T_RELEASE}"
> > PE = "5"
> > PACKAGES = "libgl-mesa libegl-mesa libgles2-mesa libgles1-mesa"
> > L4T_GLVND_DIR = "${WORKDIR}/Linux_for_Tegra/libglvnd"
> > L4T_GL_LIBRARIES = "${L4T_GLVND_DIR}/usr/lib/aarch64-linux-gnu/tegra"
> > L4T_EGL_LIBRARIES = "${L4T_GLVND_DIR}/usr/lib/aarch64-linux-gnu/tegra-egl"
> > do_unpack_append() {
> > bb.build.exec_func("unpack_l4t_tar", d)
> > }
> > unpack_l4t_tar() {
> > install -d ${L4T_GLVND_DIR}
> > tar -C ${L4T_GLVND_DIR} -x -f \
> > ${WORKDIR}/Linux_for_Tegra/nv_tegra/nvidia_drivers.tbz2 \
> > usr/lib/aarch64-linux-gnu/tegra \
> > usr/lib/aarch64-linux-gnu/tegra-egl
> > }
> > do_compile[noexec] = "1"
> > PACKAGEFUNCS_append = " rm_pkgdata_runtime"
> > rm_pkgdata_runtime() {
> > rm -rf ${WORKDIR}/pkgdata/runtime/*
> > rm -rf ${WORKDIR}/pkgdata/shlibs2/*
> > }
> > do_install() {
> > install -d ${D}${libdir}
> > # Install NVIDIA mesa libraries (libglvnd)
> > install -m755 ${L4T_GL_LIBRARIES}/libGL.so.1 
> > ${D}${libdir}/libGL.so.1.2.0
> > install -m755 ${L4T_EGL_LIBRARIES}/libEGL.so.1 
> > ${D}${libdir}/libEGL.so.1.0.0
> > install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM.so.1
> > ${D}${libdir}/libGLESv1_CM.so.1.1.0
> > install -m755 ${L4T_EGL_LIBRARIES}/libGLESv2.so.2
> > ${D}${libdir}/libGLESv2.so.2.0.0
> > ln -sf libGL.so.1.2.0 ${D}${libdir}/libGL.so.1
> > ln -sf libEGL.so.1.0.0 ${D}${libdir}/libEGL.so.1
> > ln -sf libGLESv1_CM.so.1.1.0 ${D}${libdir}/libGLESv1_CM.so.1
> > ln -sf libGLESv1_CM.so.1.1.0 ${D}${libdir}/libGLESv1_CM.so
> > ln -sf libGLESv2.so.2.0.0 ${D}${libdir}/libGLESv2.so.2
> > # Install extra NVIDIA libglvnd libraries
> > install -m755 ${L4T_GL_LIBRARIES}/libGLX.so.0 ${D}${libdir}/
> > install -m755 ${L4T_GL_LIBRARIES}/libGLdispatch.so.0 ${D}${libdir}/
> > ln -sf libGLX.so.0 ${D}${libdir}/libGLX.so
> > ln -sf libGLdispatch.so.0 ${D}${libdir}/libGLdispatch.so
> > # Install extra EGL NVIDIA libraries
> > install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM_nvidia.so.1 
> > ${D}${libdir}/
> > install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM.so.1 ${D}${libdir}/
> > install -m755 ${L4T_EGL_LIBRARIES}/libGLESv2_nvidia.so.2 ${D}${libdir}/
> > # Install extra GL NVIDIA libraries
> > install -m755 ${L4T_GL_LIBRARIES}/libGLX_nvidia.so.0 ${D}${libdir}/
> > # Install libraries dependent on libglvnd libs
> > install -m755 ${L4T_EGL_LIBRARIES}/libEGL_nvidia.so.0 ${D}${libdir}/
> > install -m755 ${L4T_GL_LIBRARIES}/libnvidia-glsi.so.28.2.1 
> > ${D}${libdir}/
> > install -m755 ${L4T_GL_LIBRARIES}/libnvbuf_utils.so.1.0.0 ${D}${libdir}/
> > ln -sf libnvbuf_utils.so.1.0.0 ${D}${libdir}/libnvbuf_utils.so.1
> > ln -sf libnvbuf_utils.so.1.0.0 ${D}${libdir}/libnvbuf_utils.so
> > install -m755 ${L4T_GL_LIBRARIES}/libnvddk_vic.so ${D}${libdir}/
> > install -m755 ${L4T_GL_LIBRARIES}/libnvddk_2d_v2.so ${D}${libdir}/
> > # nvcamera_daemon and argus_daemon have hard-coded path for this
> > install -d ${D}${nonarch_libdir}/aarch64-linux-gnu/tegra-egl
> > ln -sf 

Re: [OE-core] Two recipes providing the same .so... How it should not be done :)

2019-03-05 Thread Ricardo Ribalda Delgado
gra = "zlib libxcb-xfixes libxcb-present libdrm
libxshmfence libxcb-sync libglapi expat libxcb-dri2 libgbm libxcb-dri3
libx11 libx11-xcb"
RDEPENDS_libgles2-tegra = "libdrm libglapi"
RDEPENDS_libgles1-tegra = "libdrm libglapi"

PV = "${L4T_RELEASE}"
PE = "5"

PACKAGES = "libgl-tegra libegl-tegra libgles2-tegra libgles1-tegra"

L4T_GLVND_DIR = "${WORKDIR}/Linux_for_Tegra/libglvnd"
L4T_GL_LIBRARIES = "${L4T_GLVND_DIR}/usr/lib/aarch64-linux-gnu/tegra"
L4T_EGL_LIBRARIES = "${L4T_GLVND_DIR}/usr/lib/aarch64-linux-gnu/tegra-egl"

do_unpack_append() {
bb.build.exec_func("unpack_l4t_tar", d)
}

unpack_l4t_tar() {
install -d ${L4T_GLVND_DIR}
tar -C ${L4T_GLVND_DIR} -x -f \
${WORKDIR}/Linux_for_Tegra/nv_tegra/nvidia_drivers.tbz2 \
usr/lib/aarch64-linux-gnu/tegra \
usr/lib/aarch64-linux-gnu/tegra-egl
}

do_compile[noexec] = "1"

do_install() {
install -d ${D}${libdir}
# Install NVIDIA mesa libraries (libglvnd)
install -m755 ${L4T_GL_LIBRARIES}/libGL.so.1 ${D}${libdir}/libGL.so.1.2.0
install -m755 ${L4T_EGL_LIBRARIES}/libEGL.so.1 ${D}${libdir}/libEGL.so.1.0.0
install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM.so.1
${D}${libdir}/libGLESv1_CM.so.1.1.0
install -m755 ${L4T_EGL_LIBRARIES}/libGLESv2.so.2
${D}${libdir}/libGLESv2.so.2.0.0
ln -sf libGL.so.1.2.0 ${D}${libdir}/libGL.so.1
ln -sf libEGL.so.1.0.0 ${D}${libdir}/libEGL.so.1
ln -sf libGLESv1_CM.so.1.1.0 ${D}${libdir}/libGLESv1_CM.so.1
ln -sf libGLESv1_CM.so.1.1.0 ${D}${libdir}/libGLESv1_CM.so
ln -sf libGLESv2.so.2.0.0 ${D}${libdir}/libGLESv2.so.2

# Install extra NVIDIA libglvnd libraries
install -m755 ${L4T_GL_LIBRARIES}/libGLX.so.0 ${D}${libdir}/
install -m755 ${L4T_GL_LIBRARIES}/libGLdispatch.so.0 ${D}${libdir}/
ln -sf libGLX.so.0 ${D}${libdir}/libGLX.so
ln -sf libGLdispatch.so.0 ${D}${libdir}/libGLdispatch.so

# Install extra EGL NVIDIA libraries
install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM_nvidia.so.1 ${D}${libdir}/
install -m755 ${L4T_EGL_LIBRARIES}/libGLESv1_CM.so.1 ${D}${libdir}/
install -m755 ${L4T_EGL_LIBRARIES}/libGLESv2_nvidia.so.2 ${D}${libdir}/

# Install extra GL NVIDIA libraries
install -m755 ${L4T_GL_LIBRARIES}/libGLX_nvidia.so.0 ${D}${libdir}/

# Install libraries dependent on libglvnd libs
install -m755 ${L4T_EGL_LIBRARIES}/libEGL_nvidia.so.0 ${D}${libdir}/

install -m755 ${L4T_GL_LIBRARIES}/libnvidia-glsi.so.28.2.1 ${D}${libdir}/

install -m755 ${L4T_GL_LIBRARIES}/libnvbuf_utils.so.1.0.0 ${D}${libdir}/
ln -sf libnvbuf_utils.so.1.0.0 ${D}${libdir}/libnvbuf_utils.so.1
ln -sf libnvbuf_utils.so.1.0.0 ${D}${libdir}/libnvbuf_utils.so

install -m755 ${L4T_GL_LIBRARIES}/libnvddk_vic.so ${D}${libdir}/
install -m755 ${L4T_GL_LIBRARIES}/libnvddk_2d_v2.so ${D}${libdir}/

# nvcamera_daemon and argus_daemon have hard-coded path for this
install -d ${D}${nonarch_libdir}/aarch64-linux-gnu/tegra-egl
ln -sf ${libdir}/libEGL.so.1.0.0
${D}${nonarch_libdir}/aarch64-linux-gnu/tegra-egl/libEGL.so
}

PACKAGE_ARCH = "${MACHINE_ARCH}"

FILES_libgles1-tegra += "\
${libdir}/libGLESv1* \
"

FILES_libgles2-tegra += "\
${libdir}/libGLESv2* \
"

FILES_libegl-tegra += "\
${libdir}/libEGL* \
${nonarch_libdir}/aarch64-linux-gnu/tegra-egl/libEGL.so \
"

FILES_libgl-tegra += "\
${libdir}/libGL.* \
${libdir}/libGLX* \
${libdir}/libGLdispatch.so* \
${libdir}/libnvidia-glsi.so.28.2.1 \
${libdir}/libnvbuf_utils.so* \
${libdir}/libnvddk_vic.so  \
${libdir}/libnvddk_2d_v2.so \
"

INSANE_SKIP_${PN} = "already-stripped"
INSANE_SKIP_libegl-tegra = "ldflags dev-so"
INSANE_SKIP_libgles1-tegra = "ldflags dev-so"
INSANE_SKIP_libgles2-tegra = "ldflags"
INSANE_SKIP_libgl-tegra = "ldflags dev-so textrel"

RREPLACES_libgl-tegra = "libgl-mesa"
RREPLACES_libegl-tegra = "libegl-mesa"
RREPLACES_libgles1-tegra = "libgles1-mesa"
RREPLACES_libgles2-tegra = "libgles2-mesa"

RCONFLICTS_libgl-tegra = "libgl-mesa"
RCONFLICTS_libegl-tegra = "libegl-mesa"
RCONFLICTS_libgles1-tegra = "libgles1-mesa"
RCONFLICTS_libgles2-tegra = "libgles2-mesa"

RPROVIDES_libgl-tegra += "gl-proprietary libgl libgl-mesa"
RPROVIDES_libegl-tegra += "libegl libegl-mesa"
RPROVIDES_libgles2-tegra += "libgles2 libgles2-tegra"
RPROVIDES_libgles1-tegra += "libgles1 libgles1-tegra"


PRIVATE_LIBS = "libGL.so.1 libEGL.so.1 libGLESv2.so.2 libGLESv1_CM.so.1"

On Tue, Mar 5, 2019 at 12:06 PM Burton, Ross  wrote:
>
> That is horrible and they should be ashamed.  Can you share the
> complete recipe, as this *should* be a fairly trivial switcharoony.
>
> Ross
>
> On Tue, 5 Mar 2019 at 11:00, Rica

Re: [OE-core] Two recipes providing the same .so... How it should not be done :)

2019-03-05 Thread Ricardo Ribalda Delgado
HI Ross
On Tue, Mar 5, 2019 at 11:58 AM Burton, Ross  wrote:
>
> Does they literally just provide a libgl.so and no headers, etc?

It provides:

/usr/lib/libGL.so.1.2.0
/usr/lib/libGL.so.1


>
> Ross
>
> On Fri, 1 Mar 2019 at 11:29, Ricardo Ribalda Delgado
>  wrote:
> >
> > Hello
> >
> > I have a build system that supports some aarch64 machines. For most of
> > the them, the only difference is the kernel configuration, kernel
> > version.
> >
> > I am using multiconfig on my build server and the build goes really
> > fast thanks to all the shared binaries/artifacts.
> >
> > But I have a problem adding a new machine. This machine is also
> > aarch64, with a special kernel (nothing new here), but in this case
> > the vendor provides a binary .so for libgl that is required to get
> > hardware acceleation.
> >
> > I could .bbappend mesa and on the installation part replace libgl with
> > the new .so. But then everything that depends on mesa needs to be
> > rebuilt for that machine and I could not use multiconfig.
> >
> > Instead I have created a new recipe: mesa-gl-replace.bb that has the
> > file. This breakes completely the design of OE, but works.
> >
> > Some snipsets of the "magic" to make it work:
> >
> > #Force that the version is allways higher than the one from mesa:
> > PE = "5"
> >
> > #Rprovide the same as mesa
> > RPROVIDES_libgl-mesa += "libgl"
> >
> > #Do not overwrite pkgdata of mesa
> > PACKAGEFUNCS_append = " rm_pkgdata_runtime"
> > rm_pkgdata_runtime() {
> > rm -rf ${WORKDIR}/pkgdata/runtime/*
> > rm -rf ${WORKDIR}/pkgdata/shlibs2/*
> > }
> >
> > #Keep this on machine
> > PACKAGE_ARCH = "${MACHINE_ARCH}"
> >
> > #Make sure we are not saved as providers for libgl
> > PRIVATE_LIBS = "libGL.so.1"
> >
> > #Avoid sanity checks
> > read_subpackage_metadata () {
> > }
> >
> >
> > If your eyes have not fallen as this point, this means you have a lot
> > of tolerance for crappy code, congrats :)
> >
> > Now the question. Is there a better way to do this?
> >
> > PS: I already tried and failed with update_alternatives
> >
> >
> > Best regards!
> >
> >
> > --
> > Ricardo Ribalda
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core



-- 
Ricardo Ribalda
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] Two recipes providing the same .so... How it should not be done :)

2019-03-05 Thread Ricardo Ribalda Delgado
Epoch is set to 5, so that should not be the issue

PV = "${L4T_RELEASE}"
PE = "5"

Thanks

On Tue, Mar 5, 2019 at 10:37 AM Richard Purdie
 wrote:
>
> On Tue, 2019-03-05 at 09:27 +0100, Ricardo Ribalda Delgado wrote:
> > Hi Richard,
> >
> > Thanks for your reply!
> >
> > I tried with the following:
> >
> > INSANE_SKIP_${PN} = "already-stripped"
> > INSANE_SKIP_libegl-tegra = "ldflags dev-so"
> > INSANE_SKIP_libgles1-tegra = "ldflags dev-so"
> > INSANE_SKIP_libgles2-tegra = "ldflags"
> > INSANE_SKIP_libgl-tegra = "ldflags dev-so textrel"
> >
> > RREPLACES_libgl-tegra = "libgl-mesa"
> > RREPLACES_libegl-tegra = "libegl-mesa"
> > RREPLACES_libgles1-tegra = "libgles1-mesa"
> > RREPLACES_libgles2-tegra = "libgles2-mesa"
> >
> > RCONFLICTS_libgl-tegra = "libgl-mesa"
> > RCONFLICTS_libegl-tegra = "libegl-mesa"
> > RCONFLICTS_libgles1-tegra = "libgles1-mesa"
> > RCONFLICTS_libgles2-tegra = "libgles2-mesa"
> >
> > RPROVIDES_libgl-tegra += "gl-proprietary libgl libgl-mesa"
> > RPROVIDES_libegl-tegra += "libegl libegl-mesa"
> > RPROVIDES_libgles2-tegra += "libgles2 libgles2-tegra"
> > RPROVIDES_libgles1-tegra += "libgles1 libgles1-tegra"
> >
> > But then do_rootfs fails:
> >
> > The following packages have unmet dependencies:
> >  mesa-demos : Depends: libegl-mesa (>= 18.3.4+git0+b26488dead) but it
> > is not going to be installed
> >   Depends: libgl-mesa (>= 18.3.4+git0+b26488dead) but it
> > is not going to be installed
> >  qv4l2 : Depends: libgl-mesa (>= 18.3.4+git0+b26488dead) but it is
> > not
> > going to be installed
> >  Depends: qtbase (>= 5.11.1+git0+74305ba470) but it is not
> > going to be installed
> >
> >
> > I am forcing the installation of libgl-tegra by making:
> >
> > XSERVER += "gl-proprietary"
> >
> > What am I doing wrong :)
>
> I'd forgotten that things have hard version requirements in some of
> these dependencies :(
>
> You'd probably need to make sure your recipe has a version (or epoch,
> PE may be easier) higher than the original recipe? I think that is what
> the package manager is saying in the error above.
>
> Cheers,
>
> Richard
>


-- 
Ricardo Ribalda
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] Two recipes providing the same .so... How it should not be done :)

2019-03-05 Thread Ricardo Ribalda Delgado
Hi Richard,

Thanks for your reply!

I tried with the following:

INSANE_SKIP_${PN} = "already-stripped"
INSANE_SKIP_libegl-tegra = "ldflags dev-so"
INSANE_SKIP_libgles1-tegra = "ldflags dev-so"
INSANE_SKIP_libgles2-tegra = "ldflags"
INSANE_SKIP_libgl-tegra = "ldflags dev-so textrel"

RREPLACES_libgl-tegra = "libgl-mesa"
RREPLACES_libegl-tegra = "libegl-mesa"
RREPLACES_libgles1-tegra = "libgles1-mesa"
RREPLACES_libgles2-tegra = "libgles2-mesa"

RCONFLICTS_libgl-tegra = "libgl-mesa"
RCONFLICTS_libegl-tegra = "libegl-mesa"
RCONFLICTS_libgles1-tegra = "libgles1-mesa"
RCONFLICTS_libgles2-tegra = "libgles2-mesa"

RPROVIDES_libgl-tegra += "gl-proprietary libgl libgl-mesa"
RPROVIDES_libegl-tegra += "libegl libegl-mesa"
RPROVIDES_libgles2-tegra += "libgles2 libgles2-tegra"
RPROVIDES_libgles1-tegra += "libgles1 libgles1-tegra"

But then do_rootfs fails:

The following packages have unmet dependencies:
 mesa-demos : Depends: libegl-mesa (>= 18.3.4+git0+b26488dead) but it
is not going to be installed
  Depends: libgl-mesa (>= 18.3.4+git0+b26488dead) but it
is not going to be installed
 qv4l2 : Depends: libgl-mesa (>= 18.3.4+git0+b26488dead) but it is not
going to be installed
 Depends: qtbase (>= 5.11.1+git0+74305ba470) but it is not
going to be installed


I am forcing the installation of libgl-tegra by making:

XSERVER += "gl-proprietary"

What am I doing wrong :)

Thanks!

On Sat, Mar 2, 2019 at 1:21 PM Richard Purdie
 wrote:
>
> On Fri, 2019-03-01 at 12:28 +0100, Ricardo Ribalda Delgado wrote:
> > Hello
> >
> > I have a build system that supports some aarch64 machines. For most
> > of
> > the them, the only difference is the kernel configuration, kernel
> > version.
> >
> > I am using multiconfig on my build server and the build goes really
> > fast thanks to all the shared binaries/artifacts.
> >
> > But I have a problem adding a new machine. This machine is also
> > aarch64, with a special kernel (nothing new here), but in this case
> > the vendor provides a binary .so for libgl that is required to get
> > hardware acceleation.
> >
> > I could .bbappend mesa and on the installation part replace libgl
> > with
> > the new .so. But then everything that depends on mesa needs to be
> > rebuilt for that machine and I could not use multiconfig.
> >
> > Instead I have created a new recipe: mesa-gl-replace.bb that has the
> > file. This breakes completely the design of OE, but works.
> >
> > Some snipsets of the "magic" to make it work:
> >
> > #Force that the version is allways higher than the one from mesa:
> > PE = "5"
> >
> > #Rprovide the same as mesa
> > RPROVIDES_libgl-mesa += "libgl"
> >
> > #Do not overwrite pkgdata of mesa
> > PACKAGEFUNCS_append = " rm_pkgdata_runtime"
> > rm_pkgdata_runtime() {
> > rm -rf ${WORKDIR}/pkgdata/runtime/*
> > rm -rf ${WORKDIR}/pkgdata/shlibs2/*
> > }
> >
> > #Keep this on machine
> > PACKAGE_ARCH = "${MACHINE_ARCH}"
> >
> > #Make sure we are not saved as providers for libgl
> > PRIVATE_LIBS = "libGL.so.1"
> >
> > #Avoid sanity checks
> > read_subpackage_metadata () {
> > }
> >
> >
> > If your eyes have not fallen as this point, this means you have a lot
> > of tolerance for crappy code, congrats :)
> >
> > Now the question. Is there a better way to do this?
>
> I'd probably let mesa build as normal but then add a recipe which
> RRPROVIDES, RREPLACES and RCONFLICTS with the specific mesa package you
> want to replace. It would create and equivalent package with the right
> contents and make it machine specific.
>
> There should be more variables like PRIVATE_LIBS which stop you having
> to use the more horrible hacks (INSANE_SKIP_*?).
>
> You might then only have the issue of ensuring this machine specific
> package gets installed into the images which need GL (or just install
> it in all images for that machine).
>
> Cheers,
>
> Richard
>


-- 
Ricardo Ribalda
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] Information about non-traditional uses of the Yocto Project and OpenEmbedded

2019-03-01 Thread Ricardo Ribalda Delgado
Hi

We (qtec.com) use yocto/oe to build industrial vision systems.

Today is running on Potato graders, Carrot Graders, Potato 3d cameras,
Hyperspectral cameras, Beer analysers, Checkweighers, Screw Counters,
Hockey streamers

Let me know if you think this is interesting and I can share more detailed info.


On Wed, Feb 27, 2019 at 9:16 PM Scott Rifenbark  wrote:
>
> Sounds like good potential for a section or chapter in the user docs.
>
> Scott
>
> On Wed, Feb 27, 2019 at 12:01 PM Philip Balister  wrote:
>>
>> During the last OpenEmbedded developer meeting, it became clear that
>> people are using the Yocto project/OpenEmbedded in spaces outside what
>> we think of as traditional embedded. Lieu Ta is working on a
>> presentation for the Linux Foundation Leadership Summit and we would
>> like to collect as many "unusual" applications are possible from
>> companies we can publicly acknowledge. Unusual is edge, containers,
>> desktop, etc. Or even really interesting embedded applications :)
>>
>> Please drop me an email (off list is fine) with enough info for us to
>> add you to a slide and acknowledge your work.
>>
>> Thanks,
>>
>> Philip
>> --
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



-- 
Ricardo Ribalda
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] Two recipes providing the same .so... How it should not be done :)

2019-03-01 Thread Ricardo Ribalda Delgado
Hello

I have a build system that supports some aarch64 machines. For most of
the them, the only difference is the kernel configuration, kernel
version.

I am using multiconfig on my build server and the build goes really
fast thanks to all the shared binaries/artifacts.

But I have a problem adding a new machine. This machine is also
aarch64, with a special kernel (nothing new here), but in this case
the vendor provides a binary .so for libgl that is required to get
hardware acceleation.

I could .bbappend mesa and on the installation part replace libgl with
the new .so. But then everything that depends on mesa needs to be
rebuilt for that machine and I could not use multiconfig.

Instead I have created a new recipe: mesa-gl-replace.bb that has the
file. This breakes completely the design of OE, but works.

Some snipsets of the "magic" to make it work:

#Force that the version is allways higher than the one from mesa:
PE = "5"

#Rprovide the same as mesa
RPROVIDES_libgl-mesa += "libgl"

#Do not overwrite pkgdata of mesa
PACKAGEFUNCS_append = " rm_pkgdata_runtime"
rm_pkgdata_runtime() {
rm -rf ${WORKDIR}/pkgdata/runtime/*
rm -rf ${WORKDIR}/pkgdata/shlibs2/*
}

#Keep this on machine
PACKAGE_ARCH = "${MACHINE_ARCH}"

#Make sure we are not saved as providers for libgl
PRIVATE_LIBS = "libGL.so.1"

#Avoid sanity checks
read_subpackage_metadata () {
}


If your eyes have not fallen as this point, this means you have a lot
of tolerance for crappy code, congrats :)

Now the question. Is there a better way to do this?

PS: I already tried and failed with update_alternatives


Best regards!


-- 
Ricardo Ribalda
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] Multiconfig and native recipes

2018-12-13 Thread Ricardo Ribalda Delgado
Hi Richard

Thanks for your fast response
On Thu, Dec 13, 2018 at 5:19 PM Richard Purdie
 wrote:
>
> On Thu, 2018-12-13 at 16:19 +0100, Ricardo Ribalda Delgado wrote:
> > Hi
> >
> > I have a setup with 3 multiconfigs
> >
> > If I try to build:
> > bitbake  multiconfig:*:erlang-native
> >
> > Bitbake executes 3 tasks on the same workdir
> > tmp/work/x86_64-linux/erlang-native/
> >
> > which of course crashes. Is this expected behaviour? a bug? I have a
> > wrong config?
> >
> > Thanks!
>
> You haven't said how your configurations were different.
>
> With multiconfig you have to use it responsibly and a little caution.
>
> It sounds like you're using the same TMPDIR for these builds but the
> builds are differently configured. That wouldn't be expected to work.
> The builds can only share TMPDIR if the configurations are compatible
> with each other (same DISTRO type config, different MACHINE for
> example).
>

That is exactly my usecase. I wan to build for all the machines with
exactly the same distro:

ricardo@neopili:~/curro/yocto/europa/build$ for a in
conf/multiconfig/*; do echo $a; cat $a; done
conf/multiconfig/inteli7.conf
MACHINE = "inteli7"
conf/multiconfig/qt5022.conf
MACHINE = "qt5022"
conf/multiconfig/qt5506.conf
MACHINE = "qt5506"

I am now trying to hack bitbake/lib/bb/cooker.py to convert all tasks
multiconfig:*:A-native into A-native
it might not be the final sollution, but maybe we can use it to
discuss further options.


> Its hard to be specific without the configuration though.
>
> Cheers,
>
> Richard
>
>
>
>
>
>


-- 
Ricardo Ribalda
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] Multiconfig and native recipes

2018-12-13 Thread Ricardo Ribalda Delgado
Hi

I have a setup with 3 multiconfigs

If I try to build:
bitbake  multiconfig:*:erlang-native

Bitbake executes 3 tasks on the same workdir
tmp/work/x86_64-linux/erlang-native/

which of course crashes. Is this expected behaviour? a bug? I have a
wrong config?

Thanks!


-- 
Ricardo Ribalda
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] glibc: Fix ldd bug: not a dynamic executable error

2018-08-23 Thread Ricardo Ribalda Delgado
Hi

On Wed, Aug 22, 2018 at 4:57 PM  wrote:
>
> On Wed, 2018-08-22 at 15:39 +0200, Ricardo Ribalda Delgado wrote:
> > On Wed, Aug 22, 2018 at 3:37 PM 
> > wrote:
> > > > RTLDLIST="/lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2
> > > > /libx32/ld-linux-x32.so.
> > >
> > > I just looked at what the function is doing and its broken. What is
> > > DEFAULTTUNE set to in your build?
> >
> > DEFAULTTUNE="dbfp4"
>
> As I suspected.
>
> Try applying:
>
> http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222=d69f0127b44a5216dd21ad972d6f2b2e4cda6d13
>
> and
>
> http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222=95aa56ae11852c100be68d13aaffa9c83273b46b

After applying both:
pokyuser@3a9fc37099f7:/workdir/build$ bitbake glibc -e | grep ^RTLDLIST=
RTLDLIST="/lib/ld-linux-x86-64.so.2"

and
ricardo@neopili:~/curro/yocto/europa/build/tmp/work$ cat
dbfp4-poky-linux/glibc/2.27-r0/build-x86_64-poky-linux/elf/ldd | grep
^RTLD
RTLDLIST="/lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2
/libx32/ld-linux-x32.so.2 /lib/ld-linux-x86-64.so.2"


So it seems fixed (and more cleanly than with my patch :P)

Thanks!
>
> and then seen if that fixes things.
>
> Cheers,
>
> Richard



-- 
Ricardo Ribalda
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] glibc: Fix ldd bug: not a dynamic executable error

2018-08-22 Thread Ricardo Ribalda Delgado
Hi


On Wed, Aug 22, 2018 at 3:37 PM  wrote:
>
> On Wed, 2018-08-22 at 15:33 +0200, Ricardo Ribalda Delgado wrote:
> > Hello
> > On Wed, Aug 22, 2018 at 3:28 PM Ricardo Ribalda Delgado
> >  wrote:
> > >
> > > On Wed, Aug 22, 2018 at 3:21 PM  > > > wrote:
> > > >
> > > > On Wed, 2018-08-22 at 15:13 +0200, Ricardo Ribalda Delgado wrote:
> > > > > > Here I see:
> > > > > >
> > > > > > $ MACHINE=qemux86-64 bitbake glibc -e | grep ^RTLDLIST=
> > > > > > RTLDLIST="/lib/ld-linux-x86-64.so.2"
> > > > >
> > > > > The output of RTLDLIST that I shared was from
> > > > > root@qt5122:~# cat /usr/bin/ldd | grep ^RTLD
> > > > > RTLDLIST="/lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2
> > > > > /libx32/ld-linux-x32.so.2"
> > > > >
> > > > > If I run your command
> > > > >
> > > > > pokyuser@c10753884d1a:/workdir/build$ bitbake glibc -e | grep
> > > > > ^RTLDLIST=
> > > > > RTLDLIST=""
> > > > >
> > > > > If we look at log.do_compile we can see how the the value from
> > > > > ldd is
> > > > > rewritten:
> > > > >
> > > > > LC_ALL=C sed -e 's%@RTLD@%/lib/ld-linux-x86-64.so.2%g' -e
> > > > > 's%@VERSION@%2.27%g' -e 's|@PKGVERSION@|(GNU libc) |g' -e
> > > > > 's|@REPORT_BUGS_TO@|<http://www.gnu.org/software/libc/bugs.html
> > > > > >|g'
> > > > > -e
> > > > > 's%@BASH@%/bin/bash%g' -e 's%@TEXTDOMAINDIR@%/usr/share/locale%
> > > > > g' <
> > > > > ldd.bash.in | LC_ALL=C sed -f
> > > > > ../sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed >
> > > > > /workdir/build/tmp/work/dbfp4-poky-linux/glibc/2.27-r0/build-
> > > > > x86_64-
> > > > > poky-linux/elf/ldd.new
> > > > >
> > > > > cat git/sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed
> > > > > /LD_TRACE_LOADED_OBJECTS=1/a\
> > > > > add_env="$add_env LD_LIBRARY_VERSION=\\$verify_out"
> > > > > s_^\(RTLDLIST=\)\(.*lib\)\(\|64\|x32\)\(/[^/]*\)\(-x86-64\|-
> > > > > x32\)\(\.so\.[0-9.]*\)[
> > > > > ]*$_\1"\2\4\6 \264\4-x86-64\6 \2x32\4-x32\6 \2\3\4\5\6"_
> > > > >
> > > > > which basically converts
> > > > > /lib/ld-linux-x86-64.so.2
> > > > >  into:
> > > > >  /lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2 /libx32/ld-
> > > > > linux-
> > > > > x32.so.2
> > > > >
> > > > > I agree that this bug is too obvious for not being noticed for
> > > > > a long
> > > > > time. At least I use ldd a lot when thing fails ;)
> > > >
> > > > If you look at glibc_2.28.bb, it rewrites RTLDLIST if the value
> > > > passed
> > > > in is not empty. Yours is empty, the question is therefore why.
> > > >
> > > > Can you add -C10 to the command and see the variable history,
> > > > here its:
> > > >
> > > > # $RTLDLIST [2 operations]
> > > > #   set /media/build3/poky/meta/recipes-core/glibc/glibc-
> > > > ld.inc:46
> > > > # "${@glibc_dl_info(d)['lddrewrite']}"
> > > > #   override[class-nativesdk]:set
> > > > /media/build3/poky/meta/recipes-core/glibc/glibc-ld.inc:47
> > > > # "${base_libdir}/${@bb.utils.contains('SDK_ARCH', 'x86_64',
> > > > 'ld-linux-x86-64.so.2', 'ld-linux.so.2', d)}"
> > > > # pre-expansion value:
> > > > #   "${@glibc_dl_info(d)['lddrewrite']}"
> > > > RTLDLIST="/lib/ld-linux-x86-64.so.2"
> > > >
> > >
> > >
> > > # $RTLDLIST [2 operations]
> > > #   set /workdir/repo/poky/meta/recipes-core/glibc/glibc-ld.inc:46
> > > # "${@glibc_dl_info(d)['lddrewrite']}"
> > > #   override[class-nativesdk]:set
> > > /workdir/repo/poky/meta/recipes-core/glibc/glibc-ld.inc:47
> > > # "${base_libdir}/${@bb.utils.contains('SDK_ARCH', 'x86_64',
> > > 'ld-linux-x86-64.so.2', 'ld-linux.so.2', d)}"
> > > # pre-expansion value:
> > > #   "${@glibc_dl_info(d)['lddrewrite']}"
> > > RTLDLIST=""
> > > #
> > >
> > > # $RTLDLIST_class-nativesdk
> > > #   set /workdir/repo/poky/meta/recipes-core/glibc/glibc-ld.inc:47
> > > # "${base_libdir}/${@bb.utils.contains('SDK_ARCH', 'x86_64',
> > > 'ld-linux-x86-64.so.2', 'ld-linux.so.2', d)}"
> > > RTLDLIST_class-nativesdk="/lib/ld-linux-x86-64.so.2"
> > >
> > >
> > > I have just upgraded my work build to 19.0.1 / 2.5.1 Let me build
> > > ldd
> > > again to see if the problem still persists
> >
> > 19.0.1 gives the same results as 19.0.0
> >
> >
> > RTLDLIST="/lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2
> > /libx32/ld-linux-x32.so.
>
> I just looked at what the function is doing and its broken. What is
> DEFAULTTUNE set to in your build?

DEFAULTTUNE="dbfp4"

>
> Cheers,
>
> Richard



-- 
Ricardo Ribalda
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] glibc: Fix ldd bug: not a dynamic executable error

2018-08-22 Thread Ricardo Ribalda Delgado
Hello
On Wed, Aug 22, 2018 at 3:28 PM Ricardo Ribalda Delgado
 wrote:
>
> On Wed, Aug 22, 2018 at 3:21 PM  wrote:
> >
> > On Wed, 2018-08-22 at 15:13 +0200, Ricardo Ribalda Delgado wrote:
> > > > Here I see:
> > > >
> > > > $ MACHINE=qemux86-64 bitbake glibc -e | grep ^RTLDLIST=
> > > > RTLDLIST="/lib/ld-linux-x86-64.so.2"
> > >
> > > The output of RTLDLIST that I shared was from
> > > root@qt5122:~# cat /usr/bin/ldd | grep ^RTLD
> > > RTLDLIST="/lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2
> > > /libx32/ld-linux-x32.so.2"
> > >
> > > If I run your command
> > >
> > > pokyuser@c10753884d1a:/workdir/build$ bitbake glibc -e | grep
> > > ^RTLDLIST=
> > > RTLDLIST=""
> > >
> > > If we look at log.do_compile we can see how the the value from ldd is
> > > rewritten:
> > >
> > > LC_ALL=C sed -e 's%@RTLD@%/lib/ld-linux-x86-64.so.2%g' -e
> > > 's%@VERSION@%2.27%g' -e 's|@PKGVERSION@|(GNU libc) |g' -e
> > > 's|@REPORT_BUGS_TO@|<http://www.gnu.org/software/libc/bugs.html>|g'
> > > -e
> > > 's%@BASH@%/bin/bash%g' -e 's%@TEXTDOMAINDIR@%/usr/share/locale%g' <
> > > ldd.bash.in | LC_ALL=C sed -f
> > > ../sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed >
> > > /workdir/build/tmp/work/dbfp4-poky-linux/glibc/2.27-r0/build-x86_64-
> > > poky-linux/elf/ldd.new
> > >
> > > cat git/sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed
> > > /LD_TRACE_LOADED_OBJECTS=1/a\
> > > add_env="$add_env LD_LIBRARY_VERSION=\\$verify_out"
> > > s_^\(RTLDLIST=\)\(.*lib\)\(\|64\|x32\)\(/[^/]*\)\(-x86-64\|-
> > > x32\)\(\.so\.[0-9.]*\)[
> > > ]*$_\1"\2\4\6 \264\4-x86-64\6 \2x32\4-x32\6 \2\3\4\5\6"_
> > >
> > > which basically converts
> > > /lib/ld-linux-x86-64.so.2
> > >  into:
> > >  /lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2 /libx32/ld-linux-
> > > x32.so.2
> > >
> > > I agree that this bug is too obvious for not being noticed for a long
> > > time. At least I use ldd a lot when thing fails ;)
> >
> > If you look at glibc_2.28.bb, it rewrites RTLDLIST if the value passed
> > in is not empty. Yours is empty, the question is therefore why.
> >
> > Can you add -C10 to the command and see the variable history, here its:
> >
> > # $RTLDLIST [2 operations]
> > #   set /media/build3/poky/meta/recipes-core/glibc/glibc-ld.inc:46
> > # "${@glibc_dl_info(d)['lddrewrite']}"
> > #   override[class-nativesdk]:set 
> > /media/build3/poky/meta/recipes-core/glibc/glibc-ld.inc:47
> > # "${base_libdir}/${@bb.utils.contains('SDK_ARCH', 'x86_64', 
> > 'ld-linux-x86-64.so.2', 'ld-linux.so.2', d)}"
> > # pre-expansion value:
> > #   "${@glibc_dl_info(d)['lddrewrite']}"
> > RTLDLIST="/lib/ld-linux-x86-64.so.2"
> >
>
>
> # $RTLDLIST [2 operations]
> #   set /workdir/repo/poky/meta/recipes-core/glibc/glibc-ld.inc:46
> # "${@glibc_dl_info(d)['lddrewrite']}"
> #   override[class-nativesdk]:set
> /workdir/repo/poky/meta/recipes-core/glibc/glibc-ld.inc:47
> # "${base_libdir}/${@bb.utils.contains('SDK_ARCH', 'x86_64',
> 'ld-linux-x86-64.so.2', 'ld-linux.so.2', d)}"
> # pre-expansion value:
> #   "${@glibc_dl_info(d)['lddrewrite']}"
> RTLDLIST=""
> #
>
> # $RTLDLIST_class-nativesdk
> #   set /workdir/repo/poky/meta/recipes-core/glibc/glibc-ld.inc:47
> # "${base_libdir}/${@bb.utils.contains('SDK_ARCH', 'x86_64',
> 'ld-linux-x86-64.so.2', 'ld-linux.so.2', d)}"
> RTLDLIST_class-nativesdk="/lib/ld-linux-x86-64.so.2"
>
>
> I have just upgraded my work build to 19.0.1 / 2.5.1 Let me build ldd
> again to see if the problem still persists

19.0.1 gives the same results as 19.0.0


RTLDLIST="/lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2
/libx32/ld-linux-x32.so.


> > Cheers,
> >
> > Richard
>
>
>
> --
> Ricardo Ribalda



-- 
Ricardo Ribalda
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] glibc: Fix ldd bug: not a dynamic executable error

2018-08-22 Thread Ricardo Ribalda Delgado
On Wed, Aug 22, 2018 at 3:21 PM  wrote:
>
> On Wed, 2018-08-22 at 15:13 +0200, Ricardo Ribalda Delgado wrote:
> > > Here I see:
> > >
> > > $ MACHINE=qemux86-64 bitbake glibc -e | grep ^RTLDLIST=
> > > RTLDLIST="/lib/ld-linux-x86-64.so.2"
> >
> > The output of RTLDLIST that I shared was from
> > root@qt5122:~# cat /usr/bin/ldd | grep ^RTLD
> > RTLDLIST="/lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2
> > /libx32/ld-linux-x32.so.2"
> >
> > If I run your command
> >
> > pokyuser@c10753884d1a:/workdir/build$ bitbake glibc -e | grep
> > ^RTLDLIST=
> > RTLDLIST=""
> >
> > If we look at log.do_compile we can see how the the value from ldd is
> > rewritten:
> >
> > LC_ALL=C sed -e 's%@RTLD@%/lib/ld-linux-x86-64.so.2%g' -e
> > 's%@VERSION@%2.27%g' -e 's|@PKGVERSION@|(GNU libc) |g' -e
> > 's|@REPORT_BUGS_TO@|<http://www.gnu.org/software/libc/bugs.html>|g'
> > -e
> > 's%@BASH@%/bin/bash%g' -e 's%@TEXTDOMAINDIR@%/usr/share/locale%g' <
> > ldd.bash.in | LC_ALL=C sed -f
> > ../sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed >
> > /workdir/build/tmp/work/dbfp4-poky-linux/glibc/2.27-r0/build-x86_64-
> > poky-linux/elf/ldd.new
> >
> > cat git/sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed
> > /LD_TRACE_LOADED_OBJECTS=1/a\
> > add_env="$add_env LD_LIBRARY_VERSION=\\$verify_out"
> > s_^\(RTLDLIST=\)\(.*lib\)\(\|64\|x32\)\(/[^/]*\)\(-x86-64\|-
> > x32\)\(\.so\.[0-9.]*\)[
> > ]*$_\1"\2\4\6 \264\4-x86-64\6 \2x32\4-x32\6 \2\3\4\5\6"_
> >
> > which basically converts
> > /lib/ld-linux-x86-64.so.2
> >  into:
> >  /lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2 /libx32/ld-linux-
> > x32.so.2
> >
> > I agree that this bug is too obvious for not being noticed for a long
> > time. At least I use ldd a lot when thing fails ;)
>
> If you look at glibc_2.28.bb, it rewrites RTLDLIST if the value passed
> in is not empty. Yours is empty, the question is therefore why.
>
> Can you add -C10 to the command and see the variable history, here its:
>
> # $RTLDLIST [2 operations]
> #   set /media/build3/poky/meta/recipes-core/glibc/glibc-ld.inc:46
> # "${@glibc_dl_info(d)['lddrewrite']}"
> #   override[class-nativesdk]:set 
> /media/build3/poky/meta/recipes-core/glibc/glibc-ld.inc:47
> # "${base_libdir}/${@bb.utils.contains('SDK_ARCH', 'x86_64', 
> 'ld-linux-x86-64.so.2', 'ld-linux.so.2', d)}"
> # pre-expansion value:
> #   "${@glibc_dl_info(d)['lddrewrite']}"
> RTLDLIST="/lib/ld-linux-x86-64.so.2"
>


# $RTLDLIST [2 operations]
#   set /workdir/repo/poky/meta/recipes-core/glibc/glibc-ld.inc:46
# "${@glibc_dl_info(d)['lddrewrite']}"
#   override[class-nativesdk]:set
/workdir/repo/poky/meta/recipes-core/glibc/glibc-ld.inc:47
# "${base_libdir}/${@bb.utils.contains('SDK_ARCH', 'x86_64',
'ld-linux-x86-64.so.2', 'ld-linux.so.2', d)}"
# pre-expansion value:
#   "${@glibc_dl_info(d)['lddrewrite']}"
RTLDLIST=""
#

# $RTLDLIST_class-nativesdk
#   set /workdir/repo/poky/meta/recipes-core/glibc/glibc-ld.inc:47
# "${base_libdir}/${@bb.utils.contains('SDK_ARCH', 'x86_64',
'ld-linux-x86-64.so.2', 'ld-linux.so.2', d)}"
RTLDLIST_class-nativesdk="/lib/ld-linux-x86-64.so.2"


I have just upgraded my work build to 19.0.1 / 2.5.1 Let me build ldd
again to see if the problem still persists

> Cheers,
>
> Richard



-- 
Ricardo Ribalda
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] glibc: Fix ldd bug: not a dynamic executable error

2018-08-22 Thread Ricardo Ribalda Delgado
HI Richard

On Wed, Aug 22, 2018 at 3:05 PM  wrote:
>
> On Wed, 2018-08-22 at 15:02 +0200, Ricardo Ribalda Delgado wrote:
> > On Wed, Aug 22, 2018 at 3:00 PM 
> > wrote:
> > >
> > > On Wed, 2018-08-22 at 14:48 +0200, Ricardo Ribalda Delgado wrote:
> > > > On Wed, Aug 22, 2018 at 2:45 PM  > > > rg>
> > > > wrote:
> > > > >
> > > > > On Tue, 2018-08-21 at 16:58 +0200, Ricardo Ribalda Delgado
> > > > > wrote:
> > > > > > RTLDLIST table does not include /lib/ld-linux-x86-64.so.2,
> > > > > > resulting
> > > > > > on the following error:
> > > > > >
> > > > > > root@qt5122:~# ldd ./qtec_webcam
> > > > > > not a dynamic executable
> > > > > >
> > > > > > Signed-off-by: Ricardo Ribalda Delgado  > > > > > .com
> > > > > > >
> > > > > >
> > > > > > ---
> > > > > >  .../glibc/glibc/0031-ldd-rewrite.patch| 22
> > > > > > +++
> > > > > >  meta/recipes-core/glibc/glibc_2.28.bb |  1 +
> > > > > >  2 files changed, 23 insertions(+)
> > > > > >  create mode 100644 meta/recipes-core/glibc/glibc/0031-ldd-
> > > > > > rewrite.patch
> > > > >
> > > > > I'm a bit confused as with MACHINE=qemux86-64, building core-
> > > > > image-
> > > > > sato
> > > > > with ldd added to IMAGE_INSTALL, ldd works correctly even
> > > > > though it
> > > > > has
> > > > > /lib/ld-linux-x86-64.so.2 (which is listed in RTLDLIST).
> > > > >
> > > > > We have an automated QA test checking this too:
> > > > >
> > > > > http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/lib/oeqa/ru
> > > > > ntim
> > > > > e/cases/ldd.py
> > > > >
> > > > > Which version of the project are you using? How would we
> > > > > reproduce
> > > > > the
> > > > > issue?
> > > >
> > > > I am using yocto-sumo
> > >
> > > I'm not aware of any fixes since sumo in this area...
> > >
> > > > Maybe your tests are run agains an image that has the package lsb
> > > > installed. Which creates symbolic links to the standard locations
> > >
> > > There is no /lib64 in the image and I'm not using or installing
> > > lsb...
> > >
> > > There is significant rewriting done as part of:
> > >
> > > http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/recipes-core/gl
> > > ibc/glibc-ld.inc
> > >
> > > What value of RTLDLIST is your build showing?
> >
> > RTLDLIST="/lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2
> > /libx32/ld-linux-x32.so.2"
>
> Here I see:
>
> $ MACHINE=qemux86-64 bitbake glibc -e | grep ^RTLDLIST=
> RTLDLIST="/lib/ld-linux-x86-64.so.2"

The output of RTLDLIST that I shared was from
root@qt5122:~# cat /usr/bin/ldd | grep ^RTLD
RTLDLIST="/lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2
/libx32/ld-linux-x32.so.2"

If I run your command

pokyuser@c10753884d1a:/workdir/build$ bitbake glibc -e | grep ^RTLDLIST=
RTLDLIST=""

If we look at log.do_compile we can see how the the value from ldd is rewritten:

LC_ALL=C sed -e 's%@RTLD@%/lib/ld-linux-x86-64.so.2%g' -e
's%@VERSION@%2.27%g' -e 's|@PKGVERSION@|(GNU libc) |g' -e
's|@REPORT_BUGS_TO@|<http://www.gnu.org/software/libc/bugs.html>|g' -e
's%@BASH@%/bin/bash%g' -e 's%@TEXTDOMAINDIR@%/usr/share/locale%g' <
ldd.bash.in | LC_ALL=C sed -f
../sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed >
/workdir/build/tmp/work/dbfp4-poky-linux/glibc/2.27-r0/build-x86_64-poky-linux/elf/ldd.new

cat git/sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed
/LD_TRACE_LOADED_OBJECTS=1/a\
add_env="$add_env LD_LIBRARY_VERSION=\\$verify_out"
s_^\(RTLDLIST=\)\(.*lib\)\(\|64\|x32\)\(/[^/]*\)\(-x86-64\|-x32\)\(\.so\.[0-9.]*\)[
]*$_\1"\2\4\6 \264\4-x86-64\6 \2x32\4-x32\6 \2\3\4\5\6"_

which basically converts
/lib/ld-linux-x86-64.so.2
 into:
 /lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2 /libx32/ld-linux-x32.so.2

I agree that this bug is too obvious for not being noticed for a long
time. At least I use ldd a lot when thing fails ;)

Cheers

>
> Not sure why its different without looking at the code but its
> something to look into...
>
> Cheers,
>
> Richard



-- 
Ricardo Ribalda
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] glibc: Fix ldd bug: not a dynamic executable error

2018-08-22 Thread Ricardo Ribalda Delgado
On Wed, Aug 22, 2018 at 3:00 PM  wrote:
>
> On Wed, 2018-08-22 at 14:48 +0200, Ricardo Ribalda Delgado wrote:
> > On Wed, Aug 22, 2018 at 2:45 PM 
> > wrote:
> > >
> > > On Tue, 2018-08-21 at 16:58 +0200, Ricardo Ribalda Delgado wrote:
> > > > RTLDLIST table does not include /lib/ld-linux-x86-64.so.2,
> > > > resulting
> > > > on the following error:
> > > >
> > > > root@qt5122:~# ldd ./qtec_webcam
> > > > not a dynamic executable
> > > >
> > > > Signed-off-by: Ricardo Ribalda Delgado  > > > >
> > > > ---
> > > >  .../glibc/glibc/0031-ldd-rewrite.patch| 22
> > > > +++
> > > >  meta/recipes-core/glibc/glibc_2.28.bb |  1 +
> > > >  2 files changed, 23 insertions(+)
> > > >  create mode 100644 meta/recipes-core/glibc/glibc/0031-ldd-
> > > > rewrite.patch
> > >
> > > I'm a bit confused as with MACHINE=qemux86-64, building core-image-
> > > sato
> > > with ldd added to IMAGE_INSTALL, ldd works correctly even though it
> > > has
> > > /lib/ld-linux-x86-64.so.2 (which is listed in RTLDLIST).
> > >
> > > We have an automated QA test checking this too:
> > >
> > > http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/lib/oeqa/runtim
> > > e/cases/ldd.py
> > >
> > > Which version of the project are you using? How would we reproduce
> > > the
> > > issue?
> >
> > I am using yocto-sumo
>
> I'm not aware of any fixes since sumo in this area...
>
> > Maybe your tests are run agains an image that has the package lsb
> > installed. Which creates symbolic links to the standard locations
>
> There is no /lib64 in the image and I'm not using or installing lsb...
>
> There is significant rewriting done as part of:
>
> http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/recipes-core/glibc/glibc-ld.inc
>
> What value of RTLDLIST is your build showing?

RTLDLIST="/lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2
/libx32/ld-linux-x32.so.2"

>
> Cheers,
>
> Richard
>


-- 
Ricardo Ribalda
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] glibc: Fix ldd bug: not a dynamic executable error

2018-08-22 Thread Ricardo Ribalda Delgado
Hi Richard


On Wed, Aug 22, 2018 at 2:45 PM  wrote:
>
> On Tue, 2018-08-21 at 16:58 +0200, Ricardo Ribalda Delgado wrote:
> > RTLDLIST table does not include /lib/ld-linux-x86-64.so.2, resulting
> > on the following error:
> >
> > root@qt5122:~# ldd ./qtec_webcam
> > not a dynamic executable
> >
> > Signed-off-by: Ricardo Ribalda Delgado 
> > ---
> >  .../glibc/glibc/0031-ldd-rewrite.patch| 22
> > +++
> >  meta/recipes-core/glibc/glibc_2.28.bb |  1 +
> >  2 files changed, 23 insertions(+)
> >  create mode 100644 meta/recipes-core/glibc/glibc/0031-ldd-
> > rewrite.patch
>
> I'm a bit confused as with MACHINE=qemux86-64, building core-image-sato
> with ldd added to IMAGE_INSTALL, ldd works correctly even though it has
> /lib/ld-linux-x86-64.so.2 (which is listed in RTLDLIST).
>
> We have an automated QA test checking this too:
>
> http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/lib/oeqa/runtime/cases/ldd.py
>
> Which version of the project are you using? How would we reproduce the
> issue?
>

I am using yocto-sumo

Maybe your tests are run agains an image that has the package lsb
installed. Which creates symbolic links to the standard locations


> Regards,
>
> Richard



-- 
Ricardo Ribalda
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] glibc: Fix ldd bug: not a dynamic executable error

2018-08-21 Thread Ricardo Ribalda Delgado
RTLDLIST table does not include /lib/ld-linux-x86-64.so.2, resulting
on the following error:

root@qt5122:~# ldd ./qtec_webcam
not a dynamic executable

Signed-off-by: Ricardo Ribalda Delgado 
---
 .../glibc/glibc/0031-ldd-rewrite.patch| 22 +++
 meta/recipes-core/glibc/glibc_2.28.bb |  1 +
 2 files changed, 23 insertions(+)
 create mode 100644 meta/recipes-core/glibc/glibc/0031-ldd-rewrite.patch

diff --git a/meta/recipes-core/glibc/glibc/0031-ldd-rewrite.patch 
b/meta/recipes-core/glibc/glibc/0031-ldd-rewrite.patch
new file mode 100644
index 00..5c375997da
--- /dev/null
+++ b/meta/recipes-core/glibc/glibc/0031-ldd-rewrite.patch
@@ -0,0 +1,22 @@
+From: Ricardo Ribalda 
+Subject: Fix not a dynamic executable error on X86_64
+
+RTLDLIST table does not include /lib/ld-linux-x86-64.so.2, resulting
+on the following error:
+
+root@qt5122:~# ldd ./qtec_webcam
+not a dynamic executable
+
+
+Upstream-Status: Inappropriate  [OE-Specific]
+
+Signed-off-by: Ricardo Ribalda 
+diff --git a/sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed 
b/sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed
+index 44d76e8aa1..611efd56b0 100644
+--- a/sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed
 b/sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed
+@@ -1,3 +1,3 @@
+ /LD_TRACE_LOADED_OBJECTS=1/a\
+ add_env="$add_env LD_LIBRARY_VERSION=\\$verify_out"
+-s_^\(RTLDLIST=\)\(.*lib\)\(\|64\|x32\)\(/[^/]*\)\(-x86-64\|-x32\)\(\.so\.[0-9.]*\)[
   ]*$_\1"\2\4\6 \264\4-x86-64\6 \2x32\4-x32\6"_
++s_^\(RTLDLIST=\)\(.*lib\)\(\|64\|x32\)\(/[^/]*\)\(-x86-64\|-x32\)\(\.so\.[0-9.]*\)[
   ]*$_\1"\2\4\6 \264\4-x86-64\6 \2x32\4-x32\6 \2\3\4\5\6"_
diff --git a/meta/recipes-core/glibc/glibc_2.28.bb 
b/meta/recipes-core/glibc/glibc_2.28.bb
index 0ebbaf9610..a968c86214 100644
--- a/meta/recipes-core/glibc/glibc_2.28.bb
+++ b/meta/recipes-core/glibc/glibc_2.28.bb
@@ -45,6 +45,7 @@ SRC_URI = "${GLIBC_GIT_URI};branch=${SRCBRANCH};name=glibc \

file://0028-bits-siginfo-consts.h-enum-definition-for-TRAP_HWBKP.patch \

file://0029-localedef-add-to-archive-uses-a-hard-coded-locale-pa.patch \
file://0030-intl-Emit-no-lines-in-bison-generated-files.patch \
+   file://0031-ldd-rewrite.patch \
 "
 
 NATIVESDKFIXES ?= ""
-- 
2.18.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] x86_64: ldd does not work (not a dynamic executable)

2018-08-20 Thread Ricardo Ribalda Delgado
Hi

I think that I found a bug with ldd on sumo. Whenever I try to use it
on the target with an dynamic binary, it returns:

root@qt5122:~# ldd ./qtec_webcam
not a dynamic executable


The reason seems to be that it cannot find the dynamic linker:

It is searching for:
RTLDLIST="/lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2
/libx32/ld-linux-x32.so.2"

whith ldd being at:
/lib/ld-linux-x86-64.so.2

This can be patched on glibc with:

git diff ./sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed
diff --git a/sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed
b/sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed
index 44d76e8aa1..611efd56b0 100644
--- a/sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed
+++ b/sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed
@@ -1,3 +1,3 @@
 /LD_TRACE_LOADED_OBJECTS=1/a\
 add_env="$add_env LD_LIBRARY_VERSION=\\$verify_out"
-s_^\(RTLDLIST=\)\(.*lib\)\(\|64\|x32\)\(/[^/]*\)\(-x86-64\|-x32\)\(\.so\.[0-9.]*\)[
   ]*$_\1"\2\4\6 \264\4-x86-64\6 \2x32\4-x32\6"_
+s_^\(RTLDLIST=\)\(.*lib\)\(\|64\|x32\)\(/[^/]*\)\(-x86-64\|-x32\)\(\.so\.[0-9.]*\)[
   ]*$_\1"\2\4\6 \264\4-x86-64\6 \2x32\4-x32\6 \2\3\4\5\6"_

I can very easily make a patch for this and send it, but  it is too
strange, that I have been the first person to stumble with this thing
:), and I do not know if this is a bug OE-specific or shall I also
ping upstream.

Any ideas?

Thanks!


-- 
Ricardo Ribalda
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] Bug with multiconfig and allarch packages

2018-06-25 Thread Ricardo Ribalda Delgado
Hello

I have a setup on sumo with 4 multiconfig, 3xX86 and 1xarm64. While
building recipes that are native and allarch at the same time (from
meta-java). I am having a lot of these errors. Is this something that
is currently beeing fixed? Am I the only one seeing this?

Thanks


pokyuser@d3d188f59a44:/workdir/build$ bitbake world
Loading cache: 100%
|#|
Time: 0:00:01
Loaded 6496 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies
NOTE: Resolving any missing task queue dependencies
NOTE: Resolving any missing task queue dependencies
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION   = "1.37.0"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING  = "universal"
TARGET_SYS   = "x86_64-poky-linux"
MACHINE  = "qt5122"
DISTRO   = "poky-qtec"
DISTRO_VERSION   = "2.5"
TUNE_FEATURES= "dbfp4"
TARGET_FPU   = ""
meta
meta-poky= "HEAD:9491680e244bee211d45d3d5a9ab7ed96b7b9b6a"
meta-qtec-bsp= "HEAD:a10b73103c2baa58cc5c0c44bfd64b9d48919fe4"
meta-clang   = "HEAD:536536152263e06875722913548f9367f11ab51b"
meta-qtec-distro = "HEAD:b916f2cd20010d57979b14837424c7edc53e0d54"
meta-java= "HEAD:598499a6d222365417f1fd2e080d30277aec166c"
meta-qt5 = "HEAD:bc20e3dcd0176529740beb59ccf1f170b9f828a8"
meta-qtec-hockey = "HEAD:4d6062504a6d9983d276e6b9d6d77ae6121600c0"
meta-qtec-bottle = "HEAD:d235d301bfaa804b76a67d264e9f77b224c59104"


Build Configuration:
BB_VERSION   = "1.37.0"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING  = "universal"
TARGET_SYS   = "x86_64-poky-linux"
MACHINE  = "inteli7"
DISTRO   = "poky-qtec"
DISTRO_VERSION   = "2.5"
TUNE_FEATURES= "m64 corei7"
TARGET_FPU   = ""
meta
meta-poky= "HEAD:9491680e244bee211d45d3d5a9ab7ed96b7b9b6a"
meta-qtec-bsp= "HEAD:a10b73103c2baa58cc5c0c44bfd64b9d48919fe4"
meta-clang   = "HEAD:536536152263e06875722913548f9367f11ab51b"
meta-qtec-distro = "HEAD:b916f2cd20010d57979b14837424c7edc53e0d54"
meta-java= "HEAD:598499a6d222365417f1fd2e080d30277aec166c"
meta-qt5 = "HEAD:bc20e3dcd0176529740beb59ccf1f170b9f828a8"
meta-qtec-hockey = "HEAD:4d6062504a6d9983d276e6b9d6d77ae6121600c0"
meta-qtec-bottle = "HEAD:d235d301bfaa804b76a67d264e9f77b224c59104"


Build Configuration:
BB_VERSION   = "1.37.0"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING  = "universal"
TARGET_SYS   = "aarch64-poky-linux"
MACHINE  = "qt5506"
DISTRO   = "poky-qtec"
DISTRO_VERSION   = "2.5"
TUNE_FEATURES= "aarch64"
TARGET_FPU   = ""
meta
meta-poky= "HEAD:9491680e244bee211d45d3d5a9ab7ed96b7b9b6a"
meta-qtec-bsp= "HEAD:a10b73103c2baa58cc5c0c44bfd64b9d48919fe4"
meta-clang   = "HEAD:536536152263e06875722913548f9367f11ab51b"
meta-qtec-distro = "HEAD:b916f2cd20010d57979b14837424c7edc53e0d54"
meta-java= "HEAD:598499a6d222365417f1fd2e080d30277aec166c"
meta-qt5 = "HEAD:bc20e3dcd0176529740beb59ccf1f170b9f828a8"
meta-qtec-hockey = "HEAD:4d6062504a6d9983d276e6b9d6d77ae6121600c0"
meta-qtec-bottle = "HEAD:d235d301bfaa804b76a67d264e9f77b224c59104"


Build Configuration:
BB_VERSION   = "1.37.0"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING  = "universal"
TARGET_SYS   = "x86_64-poky-linux"
MACHINE  = "qt5022"
DISTRO   = "poky-qtec"
DISTRO_VERSION   = "2.5"
TUNE_FEATURES= "bobcat"
TARGET_FPU   = ""
meta
meta-poky= "HEAD:9491680e244bee211d45d3d5a9ab7ed96b7b9b6a"
meta-qtec-bsp= "HEAD:a10b73103c2baa58cc5c0c44bfd64b9d48919fe4"
meta-clang   = "HEAD:536536152263e06875722913548f9367f11ab51b"
meta-qtec-distro = "HEAD:b916f2cd20010d57979b14837424c7edc53e0d54"
meta-java= "HEAD:598499a6d222365417f1fd2e080d30277aec166c"
meta-qt5 = "HEAD:bc20e3dcd0176529740beb59ccf1f170b9f828a8"
meta-qtec-hockey = "HEAD:4d6062504a6d9983d276e6b9d6d77ae6121600c0"
meta-qtec-bottle = "HEAD:d235d301bfaa804b76a67d264e9f77b224c59104"

Initialising tasks: 100%
||
Time: 0:02:33
Checking sstate mirror object availability: 100%
||
Time: 0:00:00
NOTE: Executing SetScene Tasks
ERROR: mc:inteli7:cup-0.10k-r0 do_package_write_deb_setscene: Error
executing a python function in exec_python_func() autogenerated:

The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: 
 0001:
 *** 0002:do_package_write_deb_setscene(d)
 0003:
File: 

[OE-core] [PATCH] xinetd: Fix systemd service for systemd>237

2018-06-11 Thread Ricardo Ribalda Delgado
SystemD 237 implements a stricted PIDfile handling that breaks several
daemons [1].

Change the way we start xinetd, mimicing other distros [2].

Fixes:
root@qt5122:~# journalctl -u xinetd
-- Logs begin at Fri 2018-05-25 14:33:29 UTC, end at Mon 2018-06-11 07:33:08 
UTC. --
May 25 14:33:31 qt5122 systemd[1]: Starting Xinetd A Powerful Replacement For 
Inetd...
May 25 14:33:31 qt5122 systemd[1]: xinetd.service: Permission denied while 
opening PID file or unsafe symlink chain: /var/run/xinetd.pid
Jun 11 07:27:24 qt5122 systemd[1]: xinetd.service: Start operation timed out. 
Terminating.
Jun 11 07:27:24 qt5122 systemd[1]: xinetd.service: Failed with result 'timeout'.
Jun 11 07:27:24 qt5122 systemd[1]: Failed to start Xinetd A Powerful 
Replacement For Inetd.
Jun 11 07:31:38 qt5122 systemd[1]: Starting Xinetd A Powerful Replacement For 
Inetd...
Jun 11 07:31:38 qt5122 systemd[1]: xinetd.service: Permission denied while 
opening PID file or unsafe symlink chain: /var/run/xinetd.pid
Jun 11 07:33:08 qt5122 systemd[1]: xinetd.service: Start operation timed out. 
Terminating.
Jun 11 07:33:08 qt5122 systemd[1]: xinetd.service: Failed with result 'timeout'.
Jun 11 07:33:08 qt5122 systemd[1]: Failed to start Xinetd A Powerful 
Replacement For Inetd.

[1]: https://github.com/systemd/systemd/issues/8085
[2]: 
https://github.com/felixonmars/archlinux-community/commit/e49040636737fdb09031e75ec4d73a580f80676b

Signed-off-by: Ricardo Ribalda Delgado 
---
 meta/recipes-extended/xinetd/xinetd/xinetd.service | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/meta/recipes-extended/xinetd/xinetd/xinetd.service 
b/meta/recipes-extended/xinetd/xinetd/xinetd.service
index d5fdc5bc29..6da92f2bf5 100644
--- a/meta/recipes-extended/xinetd/xinetd/xinetd.service
+++ b/meta/recipes-extended/xinetd/xinetd/xinetd.service
@@ -3,11 +3,8 @@ Description=Xinetd A Powerful Replacement For Inetd
 After=syslog.target network.target
 
 [Service]
-Type=forking
-PIDFile=/var/run/xinetd.pid
 EnvironmentFile=-/etc/sysconfig/xinetd
-ExecStart=@SBINDIR@/xinetd -stayalive -pidfile /var/run/xinetd.pid 
"$EXTRAOPTIONS"
-ExecReload=@BASE_BINDIR@/kill -HUP $MAINPID
+ExecStart=@SBINDIR@/xinetd -dontfork "$EXTRAOPTIONS"
 
 [Install]
 WantedBy=multi-user.target
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] busybox: Make readlink compatible with coreutils

2018-05-24 Thread Ricardo Ribalda Delgado
Busybox readlink behaves diferently that coreutils readlink:

root@qt5122:~# touch /tmp/this_file_exist
root@qt5122:~# busybox readlink -f /tmp/this_file_exist
/tmp/this_file_exist
root@qt5122:~# readlink -f /tmp/this_file_exist
/tmp/this_file_exist

root@qt5122:~# readlink -f /tmp/this_file_does_not_exist
/tmp/this_file_does_not_exist
root@qt5122:~# busybox readlink -f /tmp/this_file_does_not_exist
root@qt5122:~#
This leads to apt-key miss-behaving and also secure apt-get

root@qt5122:~# apt-key exportall
touch: : No such file or directory

W: An error occurred during the signature verification. The repository is not 
updated and the previous index files will be used. GPG error: 
http://release.qtec.com:5022/qtec/europa/deb/qt5122 ./ Release: At least one 
invalid signature was encountered.

Signed-off-by: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
---
 .../busybox/busybox/fix-readlink-f.patch  | 96 +++
 meta/recipes-core/busybox/busybox_1.27.2.bb   |  1 +
 2 files changed, 97 insertions(+)
 create mode 100644 meta/recipes-core/busybox/busybox/fix-readlink-f.patch

diff --git a/meta/recipes-core/busybox/busybox/fix-readlink-f.patch 
b/meta/recipes-core/busybox/busybox/fix-readlink-f.patch
new file mode 100644
index 00..505fdd032f
--- /dev/null
+++ b/meta/recipes-core/busybox/busybox/fix-readlink-f.patch
@@ -0,0 +1,96 @@
+From 747162109fb1c891baf6aafa1ca0410bd08d04a4 Mon Sep 17 00:00:00 2001
+From: Denys Vlasenko <vda.li...@googlemail.com>
+Date: Thu, 24 May 2018 17:29:14 +0200
+Subject: realpath,readlink -f: coreutils compat, closes 11021
+
+function old new   delta
+xmalloc_realpath_coreutils - 121+121
+
+Signed-off-by: Denys Vlasenko <vda.li...@googlemail.com>
+Upstream-Status: Backport https://bugs.busybox.net/show_bug.cgi?id=11021
+---
+ coreutils/readlink.c |  2 +-
+ coreutils/realpath.c |  2 +-
+ include/libbb.h  |  1 +
+ libbb/xreadlink.c| 30 ++
+ 4 files changed, 33 insertions(+), 2 deletions(-)
+
+diff --git a/coreutils/readlink.c b/coreutils/readlink.c
+index b8e327d..49361ce 100644
+--- a/coreutils/readlink.c
 b/coreutils/readlink.c
+@@ -86,7 +86,7 @@ int readlink_main(int argc UNUSED_PARAM, char **argv)
+   logmode = LOGMODE_NONE;
+ 
+   if (opt & 1) { /* -f */
+-  buf = xmalloc_realpath(fname);
++  buf = xmalloc_realpath_coreutils(fname);
+   } else {
+   buf = xmalloc_readlink_or_warn(fname);
+   }
+diff --git a/coreutils/realpath.c b/coreutils/realpath.c
+index 0c2d544..d2b4bf2 100644
+--- a/coreutils/realpath.c
 b/coreutils/realpath.c
+@@ -36,7 +36,7 @@ int realpath_main(int argc UNUSED_PARAM, char **argv)
+   }
+ 
+   do {
+-  char *resolved_path = xmalloc_realpath(*argv);
++  char *resolved_path = xmalloc_realpath_coreutils(*argv);
+   if (resolved_path != NULL) {
+   puts(resolved_path);
+   free(resolved_path);
+diff --git a/include/libbb.h b/include/libbb.h
+index 8eccd81..64531c0 100644
+--- a/include/libbb.h
 b/include/libbb.h
+@@ -475,6 +475,7 @@ DIR *xopendir(const char *path) FAST_FUNC;
+ DIR *warn_opendir(const char *path) FAST_FUNC;
+ 
+ char *xmalloc_realpath(const char *path) FAST_FUNC RETURNS_MALLOC;
++char *xmalloc_realpath_coreutils(const char *path) FAST_FUNC RETURNS_MALLOC;
+ char *xmalloc_readlink(const char *path) FAST_FUNC RETURNS_MALLOC;
+ char *xmalloc_readlink_or_warn(const char *path) FAST_FUNC RETURNS_MALLOC;
+ /* !RETURNS_MALLOC: it's a realloc-like function */
+diff --git a/libbb/xreadlink.c b/libbb/xreadlink.c
+index 7d4cb60..cae322a 100644
+--- a/libbb/xreadlink.c
 b/libbb/xreadlink.c
+@@ -123,3 +123,33 @@ char* FAST_FUNC xmalloc_realpath(const char *path)
+   return xstrdup(realpath(path, buf));
+ #endif
+ }
++
++char* FAST_FUNC xmalloc_realpath_coreutils(const char *path)
++{
++  char *buf;
++
++  errno = 0;
++  buf = xmalloc_realpath(path);
++  /*
++   * There is one case when "readlink -f" and
++   * "realpath" from coreutils succeed,
++   * even though file does not exist, such as:
++   * /tmp/file_does_not_exist
++   * (the directory must exist).
++   */
++  if (!buf && errno == ENOENT) {
++  char *last_slash = strrchr(path, '/');
++  if (last_slash) {
++  *last_slash++ = '\0';
++  buf = xmalloc_realpath(path);
++  if (buf) {
++  unsigned len = strlen(buf);
++buf = xrealloc(buf, len + strlen(last_slash) 
+ 2);
++  buf[len++] = '/';
++  strcpy(buf + len, last_slash);
++  }
++  }
++  }
++
++  return buf;
++}

Re: [OE-core] [PATCH v2] apt: Port apt-file to busybox readlink

2018-05-17 Thread Ricardo Ribalda Delgado
BTW

I have just filed a bug to busybox.
https://bugs.busybox.net/show_bug.cgi?id=11021
Lets see how this evolves.


--
Ricardo Ribalda
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH v2] apt: Port apt-file to busybox readlink

2018-05-17 Thread Ricardo Ribalda Delgado
Hi Andreas

Yes, I agree. But until that happen we can fix the bug with a one liner
that works for coreutils and busybox without risking program relaying on
the wrong behaviour of busybox
On Thu, May 17, 2018 at 1:39 PM Andreas Oberritter <o...@opendreambox.org>
wrote:

> Dear Ricardo,

> On Thu, 17 May 2018 10:57:04 +0200
> Ricardo Ribalda Delgado <ricardo.riba...@gmail.com> wrote:

> > Redlink from busybox and coreutils behave differently on missing files.
> > This leads to apt-key miss-behaving and also segure apt-get

> wouldn't it be more appropriate to improve the behavior of busybox?

> Best regards,
> Andreas


> >
> > root@qt5122:~# apt-key exportall
> > touch: : No such file or directory
> >
> > W: An error occurred during the signature verification. The repository
is not updated and the previous index files will be used. GPG error:
http://release.qtec.com:5022/qtec/europa/deb/qt5122 ./ Release: At least
one invalid signature was encountered.
> >
> > Signed-off-by: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
> > ---
> > v2: Add missing signed-off-by
> >
> >  meta/recipes-devtools/apt/apt.inc |  1 +
> >  ...t-Fix-apt-file-with-busybox-readlink.patch | 41 +++
> >  2 files changed, 42 insertions(+)
> >  create mode 100644
meta/recipes-devtools/apt/apt/0001-apt-Fix-apt-file-with-busybox-readlink.patch
> >
> > diff --git a/meta/recipes-devtools/apt/apt.inc
b/meta/recipes-devtools/apt/apt.inc
> > index f1cde3068d..995bfc45ee 100644
> > --- a/meta/recipes-devtools/apt/apt.inc
> > +++ b/meta/recipes-devtools/apt/apt.inc
> > @@ -13,6 +13,7 @@ SRC_URI = "
http://archive.ubuntu.com/ubuntu/pool/main/a/${BPN}/${BPN}_${PV}.tar.
> > file://disable-test.patch \
> >
file://0001-environment.mak-musl-based-systems-can-generate-shar.patch \
> > file://0001-apt-1.2.12-Fix-musl-build.patch \
> > +   file://0001-apt-Fix-apt-file-with-busybox-readlink.patch \
> > "
> >  SRC_URI[md5sum] = "ce8f9ab11f4fd0a08ec73eaffd75c8f0"
> >  SRC_URI[sha256sum] =
"fa1311a9ce00e72379a0a3bc6d240ba30c0968cfbbb3472859e50b99e24e9598"
> > diff --git
a/meta/recipes-devtools/apt/apt/0001-apt-Fix-apt-file-with-busybox-readlink.patch
b/meta/recipes-devtools/apt/apt/0001-apt-Fix-apt-file-with-busybox-readlink.patch
> > new file mode 100644
> > index 00..684e3b1626
> > --- /dev/null
> > +++
b/meta/recipes-devtools/apt/apt/0001-apt-Fix-apt-file-with-busybox-readlink.patch
> > @@ -0,0 +1,41 @@
> > +From 3e0804f7882088186f47ff3c3c9e60998a1d93a0 Mon Sep 17 00:00:00 2001
> > +From: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
> > +Date: Thu, 17 May 2018 10:42:44 +0200
> > +Subject: [PATCH] apt: Fix apt-file with busybox readlink
> > +
> > +Busybox readlink behaves diferently that coreutils readlink:
> > +
> > +root@qt5122:~# touch /tmp/this_file_exist
> > +root@qt5122:~# busybox readlink -f /tmp/this_file_exist
> > +/tmp/this_file_exist
> > +root@qt5122:~# readlink -f /tmp/this_file_exist
> > +/tmp/this_file_exist
> > +
> > +root@qt5122:~# readlink -f /tmp/this_file_does_not_exist
> > +/tmp/this_file_does_not_exist
> > +root@qt5122:~# busybox readlink -f /tmp/this_file_does_not_exist
> > +root@qt5122:~#
> > +
> > +This patch make apt-file compatible with busybox readlink
> > +
> > +Upstream-Status: Inappropriate [OE specific]
> > +Signed-off-by: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
> > +---
> > + cmdline/apt-key.in | 1 +
> > + 1 file changed, 1 insertion(+)
> > +
> > +diff --git a/cmdline/apt-key.in b/cmdline/apt-key.in
> > +index eab5805..421c981 100644
> > +--- a/cmdline/apt-key.in
> >  b/cmdline/apt-key.in
> > +@@ -313,6 +313,7 @@ merge_all_trusted_keyrings_into_pubring() {
> > + # does the same as:
> > + # foreach_keyring_do 'import_keys_from_keyring'
"${GPGHOMEDIR}/pubring.gpg"
> > + # but without using gpg, just cat and find
> > ++touch "${GPGHOMEDIR}/pubring.gpg"
> > + local PUBRING="$(readlink -f "${GPGHOMEDIR}/pubring.gpg")"
> > + rm -f "$PUBRING"
> > + touch "$PUBRING"
> > +--
> > +2.17.0
> > +



-- 
Ricardo Ribalda
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH v2] apt: Port apt-file to busybox readlink

2018-05-17 Thread Ricardo Ribalda Delgado
Redlink from busybox and coreutils behave differently on missing files.
This leads to apt-key miss-behaving and also segure apt-get

root@qt5122:~# apt-key exportall
touch: : No such file or directory

W: An error occurred during the signature verification. The repository is not 
updated and the previous index files will be used. GPG error: 
http://release.qtec.com:5022/qtec/europa/deb/qt5122 ./ Release: At least one 
invalid signature was encountered.

Signed-off-by: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
---
v2: Add missing signed-off-by

 meta/recipes-devtools/apt/apt.inc |  1 +
 ...t-Fix-apt-file-with-busybox-readlink.patch | 41 +++
 2 files changed, 42 insertions(+)
 create mode 100644 
meta/recipes-devtools/apt/apt/0001-apt-Fix-apt-file-with-busybox-readlink.patch

diff --git a/meta/recipes-devtools/apt/apt.inc 
b/meta/recipes-devtools/apt/apt.inc
index f1cde3068d..995bfc45ee 100644
--- a/meta/recipes-devtools/apt/apt.inc
+++ b/meta/recipes-devtools/apt/apt.inc
@@ -13,6 +13,7 @@ SRC_URI = 
"http://archive.ubuntu.com/ubuntu/pool/main/a/${BPN}/${BPN}_${PV}.tar.
file://disable-test.patch \

file://0001-environment.mak-musl-based-systems-can-generate-shar.patch \
file://0001-apt-1.2.12-Fix-musl-build.patch \
+   file://0001-apt-Fix-apt-file-with-busybox-readlink.patch \
"
 SRC_URI[md5sum] = "ce8f9ab11f4fd0a08ec73eaffd75c8f0"
 SRC_URI[sha256sum] = 
"fa1311a9ce00e72379a0a3bc6d240ba30c0968cfbbb3472859e50b99e24e9598"
diff --git 
a/meta/recipes-devtools/apt/apt/0001-apt-Fix-apt-file-with-busybox-readlink.patch
 
b/meta/recipes-devtools/apt/apt/0001-apt-Fix-apt-file-with-busybox-readlink.patch
new file mode 100644
index 00..684e3b1626
--- /dev/null
+++ 
b/meta/recipes-devtools/apt/apt/0001-apt-Fix-apt-file-with-busybox-readlink.patch
@@ -0,0 +1,41 @@
+From 3e0804f7882088186f47ff3c3c9e60998a1d93a0 Mon Sep 17 00:00:00 2001
+From: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
+Date: Thu, 17 May 2018 10:42:44 +0200
+Subject: [PATCH] apt: Fix apt-file with busybox readlink
+
+Busybox readlink behaves diferently that coreutils readlink:
+
+root@qt5122:~# touch /tmp/this_file_exist
+root@qt5122:~# busybox readlink -f /tmp/this_file_exist
+/tmp/this_file_exist
+root@qt5122:~# readlink -f /tmp/this_file_exist
+/tmp/this_file_exist
+
+root@qt5122:~# readlink -f /tmp/this_file_does_not_exist
+/tmp/this_file_does_not_exist
+root@qt5122:~# busybox readlink -f /tmp/this_file_does_not_exist
+root@qt5122:~#
+
+This patch make apt-file compatible with busybox readlink
+
+Upstream-Status: Inappropriate [OE specific]
+Signed-off-by: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
+---
+ cmdline/apt-key.in | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/cmdline/apt-key.in b/cmdline/apt-key.in
+index eab5805..421c981 100644
+--- a/cmdline/apt-key.in
 b/cmdline/apt-key.in
+@@ -313,6 +313,7 @@ merge_all_trusted_keyrings_into_pubring() {
+ # does the same as:
+ # foreach_keyring_do 'import_keys_from_keyring' 
"${GPGHOMEDIR}/pubring.gpg"
+ # but without using gpg, just cat and find
++touch "${GPGHOMEDIR}/pubring.gpg"
+ local PUBRING="$(readlink -f "${GPGHOMEDIR}/pubring.gpg")"
+ rm -f "$PUBRING"
+ touch "$PUBRING"
+-- 
+2.17.0
+
-- 
2.17.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] apt: Port apt-file to busybox readlink

2018-05-17 Thread Ricardo Ribalda Delgado
Redlink from busybox and coreutils behave differently on missing files.
This leads to apt-key miss-behaving and also segure apt-get

root@qt5122:~# apt-key exportall
touch: : No such file or directory

W: An error occurred during the signature verification. The repository is not 
updated and the previous index files will be used. GPG error: 
http://release.qtec.com:5022/qtec/europa/deb/qt5122 ./ Release: At least one 
invalid signature was encountered.
---
 meta/recipes-devtools/apt/apt.inc |  1 +
 ...t-Fix-apt-file-with-busybox-readlink.patch | 41 +++
 2 files changed, 42 insertions(+)
 create mode 100644 
meta/recipes-devtools/apt/apt/0001-apt-Fix-apt-file-with-busybox-readlink.patch

diff --git a/meta/recipes-devtools/apt/apt.inc 
b/meta/recipes-devtools/apt/apt.inc
index f1cde3068d..995bfc45ee 100644
--- a/meta/recipes-devtools/apt/apt.inc
+++ b/meta/recipes-devtools/apt/apt.inc
@@ -13,6 +13,7 @@ SRC_URI = 
"http://archive.ubuntu.com/ubuntu/pool/main/a/${BPN}/${BPN}_${PV}.tar.
file://disable-test.patch \

file://0001-environment.mak-musl-based-systems-can-generate-shar.patch \
file://0001-apt-1.2.12-Fix-musl-build.patch \
+   file://0001-apt-Fix-apt-file-with-busybox-readlink.patch \
"
 SRC_URI[md5sum] = "ce8f9ab11f4fd0a08ec73eaffd75c8f0"
 SRC_URI[sha256sum] = 
"fa1311a9ce00e72379a0a3bc6d240ba30c0968cfbbb3472859e50b99e24e9598"
diff --git 
a/meta/recipes-devtools/apt/apt/0001-apt-Fix-apt-file-with-busybox-readlink.patch
 
b/meta/recipes-devtools/apt/apt/0001-apt-Fix-apt-file-with-busybox-readlink.patch
new file mode 100644
index 00..684e3b1626
--- /dev/null
+++ 
b/meta/recipes-devtools/apt/apt/0001-apt-Fix-apt-file-with-busybox-readlink.patch
@@ -0,0 +1,41 @@
+From 3e0804f7882088186f47ff3c3c9e60998a1d93a0 Mon Sep 17 00:00:00 2001
+From: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
+Date: Thu, 17 May 2018 10:42:44 +0200
+Subject: [PATCH] apt: Fix apt-file with busybox readlink
+
+Busybox readlink behaves diferently that coreutils readlink:
+
+root@qt5122:~# touch /tmp/this_file_exist
+root@qt5122:~# busybox readlink -f /tmp/this_file_exist
+/tmp/this_file_exist
+root@qt5122:~# readlink -f /tmp/this_file_exist
+/tmp/this_file_exist
+
+root@qt5122:~# readlink -f /tmp/this_file_does_not_exist
+/tmp/this_file_does_not_exist
+root@qt5122:~# busybox readlink -f /tmp/this_file_does_not_exist
+root@qt5122:~#
+
+This patch make apt-file compatible with busybox readlink
+
+Upstream-Status: Inappropriate [OE specific]
+Signed-off-by: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
+---
+ cmdline/apt-key.in | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/cmdline/apt-key.in b/cmdline/apt-key.in
+index eab5805..421c981 100644
+--- a/cmdline/apt-key.in
 b/cmdline/apt-key.in
+@@ -313,6 +313,7 @@ merge_all_trusted_keyrings_into_pubring() {
+ # does the same as:
+ # foreach_keyring_do 'import_keys_from_keyring' 
"${GPGHOMEDIR}/pubring.gpg"
+ # but without using gpg, just cat and find
++touch "${GPGHOMEDIR}/pubring.gpg"
+ local PUBRING="$(readlink -f "${GPGHOMEDIR}/pubring.gpg")"
+ rm -f "$PUBRING"
+ touch "$PUBRING"
+-- 
+2.17.0
+
-- 
2.17.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [meta-oe][PATCH] wic: Fix partition files UIDs on multi rootfs images

2018-05-11 Thread Ricardo Ribalda Delgado
When a wks makes reference to multiple rootfs, libspeudo data is not
properly chossen. This results in filesystems with invalid UIDs for all
the files.

This can be tested with this .wks file:
part / --source rootfs --fstype=ext4 --rootfs-dir=core-image-base
part /mnt/data1/ --fstype=ext4 --source rootfs --rootfs-dir=core-image-minimal
part /mnt/data2/ --fstype=ext4 --source rootfs --rootfs-dir=core-image-minimal

And this script

$bitbake core-image-minimal core-image-base syslinux
$losetup --partscan --find --read-only --show test*direct
$sudo mount /dev/loop0p1 /mnt
$ls -lan /mnt
otal 40
drwxr-xr-x 18    0    0  1024 May 11 16:11 .
drwxr-xr-x 25    0    0  4096 May  6 06:31 ..
drwxr-xr-x  2 1000 1000  3072 May 11 15:51 bin
drwxr-xr-x  2 1000 1000  1024 May 11 13:59 boot
drwxr-xr-x  2 1000 1000  1024 May 11 13:59 dev
drwxr-xr-x 25 1000 1000  3072 May 11 15:51 etc
drwxr-xr-x  3 1000 1000  1024 May 11 13:59 home
drwxr-xr-x  6 1000 1000  3072 May 11 15:51 lib
drwx--  2    0    0 12288 May 11 16:11 lost+found
drwxr-xr-x  2 1000 1000  1024 May 11 13:59 media
drwxr-xr-x  3 1000 1000  1024 May 11 15:50 mnt
drwxr-xr-x  2 1000 1000  1024 May 11 13:59 proc
drwxr-xr-x  2 1000 1000  1024 May 11 15:51 run
drwxr-xr-x  2 1000 1000  3072 May 11 15:51 sbin
drwxr-xr-x  2 1000 1000  1024 May 11 13:59 sys
drwxr-xr-t  2 1000 1000  1024 May 11 13:59 tmp
drwxr-xr-x 10 1000 1000  1024 May 11 14:54 usr
drwxr-xr-x  8 1000 1000  1024 May 11 14:55 var
$sudo losetup -d /dev/loop0

Signed-off-by: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
---
 scripts/lib/wic/partition.py | 2 +-
 scripts/lib/wic/plugins/imager/direct.py | 4 
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
index 3fe5c4e26c..c73af9d427 100644
--- a/scripts/lib/wic/partition.py
+++ b/scripts/lib/wic/partition.py
@@ -211,7 +211,7 @@ class Partition():
 """
 p_prefix = os.environ.get("PSEUDO_PREFIX", "%s/usr" % native_sysroot)
 p_localstatedir = os.environ.get("PSEUDO_LOCALSTATEDIR",
- "%s/../pseudo" %  
get_bitbake_var("IMAGE_ROOTFS"))
+ "%s/../pseudo" %  rootfs_dir)
 p_passwd = os.environ.get("PSEUDO_PASSWD", rootfs_dir)
 p_nosymlinkexp = os.environ.get("PSEUDO_NOSYMLINKEXP", "1")
 pseudo = "export PSEUDO_PREFIX=%s;" % p_prefix
diff --git a/scripts/lib/wic/plugins/imager/direct.py 
b/scripts/lib/wic/plugins/imager/direct.py
index 1fa6b917e6..81583e97b9 100644
--- a/scripts/lib/wic/plugins/imager/direct.py
+++ b/scripts/lib/wic/plugins/imager/direct.py
@@ -122,6 +122,10 @@ class DirectPlugin(ImagerPlugin):
 if self._update_fstab(fstab_lines, self.parts):
 # copy rootfs dir to workdir to update fstab
 # as rootfs can be used by other tasks and can't be modified
+new_pseudo = os.path.realpath(os.path.join(self.workdir, "pseudo"))
+from_dir = os.path.join(os.path.join(image_rootfs, ".."), "pseudo")
+from_dir = os.path.realpath(from_dir)
+copyhardlinktree(from_dir, new_pseudo)
 new_rootfs = os.path.realpath(os.path.join(self.workdir, 
"rootfs_copy"))
 copyhardlinktree(image_rootfs, new_rootfs)
 fstab_path = os.path.join(new_rootfs, 'etc/fstab')
-- 
2.17.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] Question about multi rootfs UIDs when using wic

2018-05-11 Thread Ricardo Ribalda Delgado
Hello

So this is what I have tried out:

I have downloaded master from openembedded-core
(f04e6bd144deb0c8fe2742f66b18904b6619a502)
then:
bitbake core-image-minimal core-image-base syslinux

Create a file  test.wks
part / --source rootfs --fstype=ext4 --rootfs-dir=core-image-base
part /mnt/data1/ --fstype=ext4 --source rootfs
--rootfs-dir=core-image-minimal
part /mnt/data2/ --fstype=ext4 --source rootfs
--rootfs-dir=core-image-minimal

bootloader --timeout=0


Then:
losetup --partscan --find --read-only --show test*direct
sudo mount /dev/loop0p1 /mnt
ls -lan /mnt
total 40
drwxr-xr-x 1800  1024 May 11 16:11 .
drwxr-xr-x 2500  4096 May  6 06:31 ..
drwxr-xr-x  2 1000 1000  3072 May 11 15:51 bin
drwxr-xr-x  2 1000 1000  1024 May 11 13:59 boot
drwxr-xr-x  2 1000 1000  1024 May 11 13:59 dev
drwxr-xr-x 25 1000 1000  3072 May 11 15:51 etc
drwxr-xr-x  3 1000 1000  1024 May 11 13:59 home
drwxr-xr-x  6 1000 1000  3072 May 11 15:51 lib
drwx--  200 12288 May 11 16:11 lost+found
drwxr-xr-x  2 1000 1000  1024 May 11 13:59 media
drwxr-xr-x  3 1000 1000  1024 May 11 15:50 mnt
drwxr-xr-x  2 1000 1000  1024 May 11 13:59 proc
drwxr-xr-x  2 1000 1000  1024 May 11 15:51 run
drwxr-xr-x  2 1000 1000  3072 May 11 15:51 sbin
drwxr-xr-x  2 1000 1000  1024 May 11 13:59 sys
drwxr-xr-t  2 1000 1000  1024 May 11 13:59 tmp
drwxr-xr-x 10 1000 1000  1024 May 11 14:54 usr
drwxr-xr-x  8 1000 1000  1024 May 11 14:55 var


With my patch:
ricardo@neopili:/tmp/openembedded-core/build$ ls -lan /mnt
total 40
drwxr-xr-x 18 0 0  1024 May 11 16:18 .
drwxr-xr-x 25 0 0  4096 May  6 06:31 ..
drwxr-xr-x  2 0 0  3072 May 11 15:51 bin
drwxr-xr-x  2 0 0  1024 May 11 13:59 boot
drwxr-xr-x  2 0 0  1024 May 11 13:59 dev
drwxr-xr-x 25 0 0  3072 May 11 15:51 etc
drwxr-xr-x  3 0 0  1024 May 11 13:59 home
drwxr-xr-x  6 0 0  3072 May 11 15:51 lib
drwx--  2 0 0 12288 May 11 16:18 lost+found
drwxr-xr-x  2 0 0  1024 May 11 13:59 media
drwxr-xr-x  3 0 0  1024 May 11 15:50 mnt
drwxr-xr-x  2 0 0  1024 May 11 13:59 proc
drwxr-xr-x  2 0 0  1024 May 11 15:51 run
drwxr-xr-x  2 0 0  3072 May 11 15:51 sbin
drwxr-xr-x  2 0 0  1024 May 11 13:59 sys
drwxrwxrwt  2 0 0  1024 May 11 13:59 tmp
drwxr-xr-x 10 0 0  1024 May 11 14:54 usr
drwxr-xr-x  8 0 0  1024 May 11 14:55 var


I think that I am going to send a formal patch to the mailing list and see
if we get some feedback


Cheers!

On Tue, May 8, 2018 at 3:39 PM Volker Vogelhuber <
v.vogelhu...@digitalendoscopy.de> wrote:

> Hi Ricardo,

> On 07.05.2018 15:22, Ricardo Ribalda Delgado wrote:
> > In my case this patch does the trick
> Unfortunately your patch results in having the recovery image's UID and
> GID settings to be set to my current user instead of root. So no, your
> patch does not seem to work for me.
> I didn't have the time to check in detail what's wrong with your version.

> >
> > commit 269334f2400c6ee0c7b4fec7d9bf0f701e50c329 (HEAD -> europa,
origin/europa)
> > Author: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
> > Date:   Mon May 7 13:54:15 2018 +0200
> >
> >  wic: Fix partition files UIDs on multi rootfs images
> >
> > diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
> > index 84fe85d62b..49921e7494 100644
> > --- a/scripts/lib/wic/partition.py
> > +++ b/scripts/lib/wic/partition.py
> > @@ -206,7 +206,7 @@ class Partition():
> >   """
> >   p_prefix = os.environ.get("PSEUDO_PREFIX", "%s/usr" %
native_sysroot)
> >   p_localstatedir = os.environ.get("PSEUDO_LOCALSTATEDIR",
> > - "%s/../pseudo" %
> > get_bitbake_var("IMAGE_ROOTFS"))
> > + "%s/../pseudo" %  rootfs_dir)
> >   p_passwd = os.environ.get("PSEUDO_PASSWD", rootfs_dir)
> >   p_nosymlinkexp = os.environ.get("PSEUDO_NOSYMLINKEXP", "1")
> >   pseudo = "export PSEUDO_PREFIX=%s;" % p_prefix
> > diff --git a/scripts/lib/wic/plugins/imager/direct.py
> > b/scripts/lib/wic/plugins/imager/direct.py
> > index da1c061063..a90a47c926 100644
> > --- a/scripts/lib/wic/plugins/imager/direct.py
> > +++ b/scripts/lib/wic/plugins/imager/direct.py
> > @@ -121,6 +121,10 @@ class DirectPlugin(ImagerPlugin):
> >   if self._update_fstab(fstab_lines, self.parts):
> >   # copy rootfs dir to workdir to update fstab
> >   # as rootfs can be used by other tasks and can't be
modified
> > +new_pseudo = os.path.realpath(os.path.join(self.workdir,
"pseudo"))
> > +from_dir = os.path.join(os.path.join(image_rootfs, ".."),
"pseudo")
> > +from_dir 

Re: [OE-core] Question about multi rootfs UIDs when using wic

2018-05-07 Thread Ricardo Ribalda Delgado
Hi Volker

I have tried your patch and does not work for me :(. My configuration
is a little bit more complex, I have two different machines.

The images are generated with:

host-kiosk.wks:

part /boot/bootloader --source qbootimg-efi --ondisk sda --active
--align 1024 --use-uuid --fsoptions defaults,ro
part /export --source rootfs --rootfs-dir=kiosk-image --ondisk sda
--fstype=ext4 --label export --align 1024 --use-uuid --fsoptions
defaults,ro
part / --source rootfs --ondisk sda --fstype=ext4 --label rootfs
--align 1024 --use-uuid --fsoptions defaults,ro

bootloader --ptable gpt --timeout=1 --append="ro rootfstype=ext4
qtec_mem.size=64


MACHINE=qt5022 bitbake host-image ; MACHINE=qt5122 bitbake kiosk-image
wic create host-kiosk -e host-image --rootfs-dir
kiosk-image=/workdir/build/tmp/work/qt5122-poky-linux/kiosk-image/1.0-r0/rootfs/
--rootfs-dir /workdir/build/tmp/work/qt5022-poky-linux/host-image/1.0-r0/rootfs/
-m


In my case this patch does the trick

commit 269334f2400c6ee0c7b4fec7d9bf0f701e50c329 (HEAD -> europa, origin/europa)
Author: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
Date:   Mon May 7 13:54:15 2018 +0200

wic: Fix partition files UIDs on multi rootfs images

diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
index 84fe85d62b..49921e7494 100644
--- a/scripts/lib/wic/partition.py
+++ b/scripts/lib/wic/partition.py
@@ -206,7 +206,7 @@ class Partition():
 """
 p_prefix = os.environ.get("PSEUDO_PREFIX", "%s/usr" % native_sysroot)
 p_localstatedir = os.environ.get("PSEUDO_LOCALSTATEDIR",
- "%s/../pseudo" %
get_bitbake_var("IMAGE_ROOTFS"))
+ "%s/../pseudo" %  rootfs_dir)
 p_passwd = os.environ.get("PSEUDO_PASSWD", rootfs_dir)
 p_nosymlinkexp = os.environ.get("PSEUDO_NOSYMLINKEXP", "1")
 pseudo = "export PSEUDO_PREFIX=%s;" % p_prefix
diff --git a/scripts/lib/wic/plugins/imager/direct.py
b/scripts/lib/wic/plugins/imager/direct.py
index da1c061063..a90a47c926 100644
--- a/scripts/lib/wic/plugins/imager/direct.py
+++ b/scripts/lib/wic/plugins/imager/direct.py
@@ -121,6 +121,10 @@ class DirectPlugin(ImagerPlugin):
 if self._update_fstab(fstab_lines, self.parts):
 # copy rootfs dir to workdir to update fstab
 # as rootfs can be used by other tasks and can't be modified
+new_pseudo = os.path.realpath(os.path.join(self.workdir, "pseudo"))
+from_dir = os.path.join(os.path.join(image_rootfs, ".."), "pseudo")
+from_dir = os.path.realpath(from_dir)
+copyhardlinktree(from_dir, new_pseudo)
 new_rootfs = os.path.realpath(os.path.join(self.workdir,
"rootfs_copy"))
 copyhardlinktree(image_rootfs, new_rootfs)
 fstab_path = os.path.join(new_rootfs, 'etc/fstab')



Can you try it on your setup? If it also works for you I will work on
getting it merged.


Cheers!

On Wed, May 2, 2018 at 8:25 PM, Ricardo Ribalda Delgado
<ricardo.riba...@gmail.com> wrote:
> cc: ed
>
> Is it a very bad idea to revert your patch?
>
> Thanks!
>
> On Wed, May 2, 2018 at 8:17 PM, Ricardo Ribalda Delgado
> <ricardo.riba...@gmail.com> wrote:
>> Hi
>>
>> I do not know how many people is actively using wic. We have started
>> using it from last week, it is hard to replace old scripts that work
>> :)
>>
>> Try sending it as a proper patch, I can help you if you need it.
>>
>> Regards
>>
>> On Wed, May 2, 2018 at 6:31 PM, Volker Vogelhuber
>> <v.vogelhu...@digitalendoscopy.de> wrote:
>>> Hi,
>>>
>>> I never got any response to my message (until now). So AFAIK I solved the
>>> problem with the following patch:
>>>
>>> diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
>>> index 84fe85d62b..66ab757aec 100644
>>> --- a/scripts/lib/wic/partition.py
>>> +++ b/scripts/lib/wic/partition.py
>>> @@ -204,15 +204,10 @@ class Partition():
>>>
>>>  Currently handles ext2/3/4, btrfs and vfat.
>>>  """
>>> -p_prefix = os.environ.get("PSEUDO_PREFIX", "%s/usr" %
>>> native_sysroot)
>>> -p_localstatedir = os.environ.get("PSEUDO_LOCALSTATEDIR",
>>> - "%s/../pseudo" %
>>> get_bitbake_var("IMAGE_ROOTFS"))
>>> -p_passwd = os.environ.get("PSEUDO_PASSWD", rootfs_dir)
>>> +pseudo = "export PSEUDO_PREFIX=%s/usr;" % native_sysroot
>&

Re: [OE-core] Question about multi rootfs UIDs when using wic

2018-05-02 Thread Ricardo Ribalda Delgado
cc: ed

Is it a very bad idea to revert your patch?

Thanks!

On Wed, May 2, 2018 at 8:17 PM, Ricardo Ribalda Delgado
<ricardo.riba...@gmail.com> wrote:
> Hi
>
> I do not know how many people is actively using wic. We have started
> using it from last week, it is hard to replace old scripts that work
> :)
>
> Try sending it as a proper patch, I can help you if you need it.
>
> Regards
>
> On Wed, May 2, 2018 at 6:31 PM, Volker Vogelhuber
> <v.vogelhu...@digitalendoscopy.de> wrote:
>> Hi,
>>
>> I never got any response to my message (until now). So AFAIK I solved the
>> problem with the following patch:
>>
>> diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
>> index 84fe85d62b..66ab757aec 100644
>> --- a/scripts/lib/wic/partition.py
>> +++ b/scripts/lib/wic/partition.py
>> @@ -204,15 +204,10 @@ class Partition():
>>
>>  Currently handles ext2/3/4, btrfs and vfat.
>>  """
>> -p_prefix = os.environ.get("PSEUDO_PREFIX", "%s/usr" %
>> native_sysroot)
>> -p_localstatedir = os.environ.get("PSEUDO_LOCALSTATEDIR",
>> - "%s/../pseudo" %
>> get_bitbake_var("IMAGE_ROOTFS"))
>> -p_passwd = os.environ.get("PSEUDO_PASSWD", rootfs_dir)
>> +pseudo = "export PSEUDO_PREFIX=%s/usr;" % native_sysroot
>> +pseudo += "export PSEUDO_LOCALSTATEDIR=%s/../pseudo;" %
>> self.rootfs_dir
>> +pseudo += "export PSEUDO_PASSWD=%s;" % rootfs_dir
>>  p_nosymlinkexp = os.environ.get("PSEUDO_NOSYMLINKEXP", "1")
>> -pseudo = "export PSEUDO_PREFIX=%s;" % p_prefix
>> -pseudo += "export PSEUDO_LOCALSTATEDIR=%s;" % p_localstatedir
>> -pseudo += "export PSEUDO_PASSWD=%s;" % p_passwd
>> -pseudo += "export PSEUDO_NOSYMLINKEXP=%s;" % p_nosymlinkexp
>>  pseudo += "%s " % get_bitbake_var("FAKEROOTCMD")
>>
>>  rootfs = "%s/rootfs_%s.%s.%s" % (cr_workdir, self.label,
>>
>>
>>
>> On 02.05.2018 17:51, Ricardo Ribalda Delgado wrote:
>>>
>>> Hi
>>>
>>> I just got hit by this one. It is specially nasty because nfsroot
>>> fails to boot if the uids are wrong.
>>>
>>> What is the status on this?
>>>
>>> On Mon, Jan 22, 2018 at 11:39 AM, Volker Vogelhuber
>>> <v.vogelhu...@digitalendoscopy.de> wrote:
>>>>
>>>> I finally found out, what's the reason why the included recovery rootfs
>>>> has
>>>> the wrong UIDs, while the main image has the correct one. The reason
>>>> seems
>>>> to be the PSEUDO_LOCALSTATEDIR variable that is set to the state dir of
>>>> the
>>>> main image in both cases.
>>>> I debugged all the calls up to the environment setup in partition.py's
>>>> prepare_rootfs method where a check for an existing PSEUDO_LOCALSTATEDIR
>>>> environment variable is done. That seems to be the problem.
>>>> Instead of using the correct value passed to the prepare_rootfs method,
>>>> an
>>>> existing ENV value is used that points to the state dir of the main image
>>>> instead of the recovery one's. I guess the reason is that in bitbake.conf
>>>> the PSEUDO_LOCALSTATEDIR is set to the image currently build (which is
>>>> the
>>>> main image and not the recovery image only referenced by the main image).
>>>> So
>>>> because that environment variable is already set, the call to mkfs.ext4
>>>> for
>>>> the recovery image uses the wrong PSEUDO_LOCALSTATEDIR and does not apply
>>>> the correct UID.
>>>>
>>>> Any ideas how to fix that? I tend to just remove the patch introduced by
>>>> Ed
>>>> Bartosh three years ago (https://patchwork.openembedded.org/patch/90419/)
>>>> because I don't need a custom PSEUDO_PREFIX. But maybe not everyone
>>>> agrees.
>>>>
>>>> On 19.01.2018 17:00, Volker Vogelhuber wrote:
>>>>>
>>>>>
>>>>> I'm currently trying to create a multi RootFS WIC image as mentioned in
>>>>> directdisk-multi-rootfs.wks. For that I have two image recipes. One that
>>>>> is creating only an ext4 image (image-recovery), and the second that is
>>>>> also
>>>>> creating a WIC ima

Re: [OE-core] Question about multi rootfs UIDs when using wic

2018-05-02 Thread Ricardo Ribalda Delgado
Hi

I do not know how many people is actively using wic. We have started
using it from last week, it is hard to replace old scripts that work
:)

Try sending it as a proper patch, I can help you if you need it.

Regards

On Wed, May 2, 2018 at 6:31 PM, Volker Vogelhuber
<v.vogelhu...@digitalendoscopy.de> wrote:
> Hi,
>
> I never got any response to my message (until now). So AFAIK I solved the
> problem with the following patch:
>
> diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
> index 84fe85d62b..66ab757aec 100644
> --- a/scripts/lib/wic/partition.py
> +++ b/scripts/lib/wic/partition.py
> @@ -204,15 +204,10 @@ class Partition():
>
>  Currently handles ext2/3/4, btrfs and vfat.
>  """
> -p_prefix = os.environ.get("PSEUDO_PREFIX", "%s/usr" %
> native_sysroot)
> -p_localstatedir = os.environ.get("PSEUDO_LOCALSTATEDIR",
> - "%s/../pseudo" %
> get_bitbake_var("IMAGE_ROOTFS"))
> -p_passwd = os.environ.get("PSEUDO_PASSWD", rootfs_dir)
> +pseudo = "export PSEUDO_PREFIX=%s/usr;" % native_sysroot
> +pseudo += "export PSEUDO_LOCALSTATEDIR=%s/../pseudo;" %
> self.rootfs_dir
> +pseudo += "export PSEUDO_PASSWD=%s;" % rootfs_dir
>  p_nosymlinkexp = os.environ.get("PSEUDO_NOSYMLINKEXP", "1")
> -pseudo = "export PSEUDO_PREFIX=%s;" % p_prefix
> -pseudo += "export PSEUDO_LOCALSTATEDIR=%s;" % p_localstatedir
> -pseudo += "export PSEUDO_PASSWD=%s;" % p_passwd
> -    pseudo += "export PSEUDO_NOSYMLINKEXP=%s;" % p_nosymlinkexp
>  pseudo += "%s " % get_bitbake_var("FAKEROOTCMD")
>
>  rootfs = "%s/rootfs_%s.%s.%s" % (cr_workdir, self.label,
>
>
>
> On 02.05.2018 17:51, Ricardo Ribalda Delgado wrote:
>>
>> Hi
>>
>> I just got hit by this one. It is specially nasty because nfsroot
>> fails to boot if the uids are wrong.
>>
>> What is the status on this?
>>
>> On Mon, Jan 22, 2018 at 11:39 AM, Volker Vogelhuber
>> <v.vogelhu...@digitalendoscopy.de> wrote:
>>>
>>> I finally found out, what's the reason why the included recovery rootfs
>>> has
>>> the wrong UIDs, while the main image has the correct one. The reason
>>> seems
>>> to be the PSEUDO_LOCALSTATEDIR variable that is set to the state dir of
>>> the
>>> main image in both cases.
>>> I debugged all the calls up to the environment setup in partition.py's
>>> prepare_rootfs method where a check for an existing PSEUDO_LOCALSTATEDIR
>>> environment variable is done. That seems to be the problem.
>>> Instead of using the correct value passed to the prepare_rootfs method,
>>> an
>>> existing ENV value is used that points to the state dir of the main image
>>> instead of the recovery one's. I guess the reason is that in bitbake.conf
>>> the PSEUDO_LOCALSTATEDIR is set to the image currently build (which is
>>> the
>>> main image and not the recovery image only referenced by the main image).
>>> So
>>> because that environment variable is already set, the call to mkfs.ext4
>>> for
>>> the recovery image uses the wrong PSEUDO_LOCALSTATEDIR and does not apply
>>> the correct UID.
>>>
>>> Any ideas how to fix that? I tend to just remove the patch introduced by
>>> Ed
>>> Bartosh three years ago (https://patchwork.openembedded.org/patch/90419/)
>>> because I don't need a custom PSEUDO_PREFIX. But maybe not everyone
>>> agrees.
>>>
>>> On 19.01.2018 17:00, Volker Vogelhuber wrote:
>>>>
>>>>
>>>> I'm currently trying to create a multi RootFS WIC image as mentioned in
>>>> directdisk-multi-rootfs.wks. For that I have two image recipes. One that
>>>> is creating only an ext4 image (image-recovery), and the second that is
>>>> also
>>>> creating a WIC image (image-main). I used the IMAGE_FSTYPES variable for
>>>> that. The WKS file for the second image is integrating the recovery
>>>> image by
>>>> specifying --rootfs-dir=image-recovery in it's part description.
>>>>
>>>> # primary / recovery image
>>>> part / --source rootfs --rootfs-dir=image-main --exclude-path mnt/data/
>>>> mnt/data2/ --fstype=ext4 --label primary_rootfs --align 1024 --size 700
>>>> --overhead-factor=1.0
>>>> par

Re: [OE-core] Question about multi rootfs UIDs when using wic

2018-05-02 Thread Ricardo Ribalda Delgado
Hi Scott

In this case I believe that it is a bug in wic, for no reason the user
id of bitbake should be leaked into the rootfs.

Regards

On Wed, May 2, 2018 at 6:44 PM, Scott Rifenbark <srifenb...@gmail.com> wrote:
> Hi,
>
> I have a couple Wic-related areas in the Yocto documentation.  Wondering if
> this affects documentation.  I don't particularly have sections dedicated to
> using specific canned wic files such as the "directdisk-multi-rootfs" file.
> However, if there is some mentioning or changing of the docs to help avoid
> this I could see what I could do.
>
> The sections related to Wic are:
>
>*
> https://www.yoctoproject.org/docs/2.5/dev-manual/dev-manual.html#creating-partitioned-images-using-wic
>*
> https://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#ref-kickstart
>
> Thanks,
> Scott
>
> On Wed, May 2, 2018 at 9:31 AM, Volker Vogelhuber
> <v.vogelhu...@digitalendoscopy.de> wrote:
>>
>> Hi,
>>
>> I never got any response to my message (until now). So AFAIK I solved the
>> problem with the following patch:
>>
>> diff --git a/scripts/lib/wic/partition.py b/scripts/lib/wic/partition.py
>> index 84fe85d62b..66ab757aec 100644
>> --- a/scripts/lib/wic/partition.py
>> +++ b/scripts/lib/wic/partition.py
>> @@ -204,15 +204,10 @@ class Partition():
>>
>>  Currently handles ext2/3/4, btrfs and vfat.
>>  """
>> -p_prefix = os.environ.get("PSEUDO_PREFIX", "%s/usr" %
>> native_sysroot)
>> -p_localstatedir = os.environ.get("PSEUDO_LOCALSTATEDIR",
>> - "%s/../pseudo" %
>> get_bitbake_var("IMAGE_ROOTFS"))
>> -p_passwd = os.environ.get("PSEUDO_PASSWD", rootfs_dir)
>> +pseudo = "export PSEUDO_PREFIX=%s/usr;" % native_sysroot
>> +pseudo += "export PSEUDO_LOCALSTATEDIR=%s/../pseudo;" %
>> self.rootfs_dir
>> +pseudo += "export PSEUDO_PASSWD=%s;" % rootfs_dir
>>  p_nosymlinkexp = os.environ.get("PSEUDO_NOSYMLINKEXP", "1")
>> -pseudo = "export PSEUDO_PREFIX=%s;" % p_prefix
>> -    pseudo += "export PSEUDO_LOCALSTATEDIR=%s;" % p_localstatedir
>> -pseudo += "export PSEUDO_PASSWD=%s;" % p_passwd
>> -pseudo += "export PSEUDO_NOSYMLINKEXP=%s;" % p_nosymlinkexp
>>  pseudo += "%s " % get_bitbake_var("FAKEROOTCMD")
>>
>>  rootfs = "%s/rootfs_%s.%s.%s" % (cr_workdir, self.label,
>>
>>
>>
>> On 02.05.2018 17:51, Ricardo Ribalda Delgado wrote:
>>>
>>> Hi
>>>
>>> I just got hit by this one. It is specially nasty because nfsroot
>>> fails to boot if the uids are wrong.
>>>
>>> What is the status on this?
>>>
>>> On Mon, Jan 22, 2018 at 11:39 AM, Volker Vogelhuber
>>> <v.vogelhu...@digitalendoscopy.de> wrote:
>>>>
>>>> I finally found out, what's the reason why the included recovery rootfs
>>>> has
>>>> the wrong UIDs, while the main image has the correct one. The reason
>>>> seems
>>>> to be the PSEUDO_LOCALSTATEDIR variable that is set to the state dir of
>>>> the
>>>> main image in both cases.
>>>> I debugged all the calls up to the environment setup in partition.py's
>>>> prepare_rootfs method where a check for an existing PSEUDO_LOCALSTATEDIR
>>>> environment variable is done. That seems to be the problem.
>>>> Instead of using the correct value passed to the prepare_rootfs method,
>>>> an
>>>> existing ENV value is used that points to the state dir of the main
>>>> image
>>>> instead of the recovery one's. I guess the reason is that in
>>>> bitbake.conf
>>>> the PSEUDO_LOCALSTATEDIR is set to the image currently build (which is
>>>> the
>>>> main image and not the recovery image only referenced by the main
>>>> image). So
>>>> because that environment variable is already set, the call to mkfs.ext4
>>>> for
>>>> the recovery image uses the wrong PSEUDO_LOCALSTATEDIR and does not
>>>> apply
>>>> the correct UID.
>>>>
>>>> Any ideas how to fix that? I tend to just remove the patch introduced by
>>>> Ed
>>>> Bartosh three years ago
>>>> (https://patchwork.openembedded.org/patch/90419/)
>>>

Re: [OE-core] Question about multi rootfs UIDs when using wic

2018-05-02 Thread Ricardo Ribalda Delgado
Hi

I just got hit by this one. It is specially nasty because nfsroot
fails to boot if the uids are wrong.

What is the status on this?

On Mon, Jan 22, 2018 at 11:39 AM, Volker Vogelhuber
 wrote:
> I finally found out, what's the reason why the included recovery rootfs has
> the wrong UIDs, while the main image has the correct one. The reason seems
> to be the PSEUDO_LOCALSTATEDIR variable that is set to the state dir of the
> main image in both cases.
> I debugged all the calls up to the environment setup in partition.py's
> prepare_rootfs method where a check for an existing PSEUDO_LOCALSTATEDIR
> environment variable is done. That seems to be the problem.
> Instead of using the correct value passed to the prepare_rootfs method, an
> existing ENV value is used that points to the state dir of the main image
> instead of the recovery one's. I guess the reason is that in bitbake.conf
> the PSEUDO_LOCALSTATEDIR is set to the image currently build (which is the
> main image and not the recovery image only referenced by the main image). So
> because that environment variable is already set, the call to mkfs.ext4 for
> the recovery image uses the wrong PSEUDO_LOCALSTATEDIR and does not apply
> the correct UID.
>
> Any ideas how to fix that? I tend to just remove the patch introduced by Ed
> Bartosh three years ago (https://patchwork.openembedded.org/patch/90419/)
> because I don't need a custom PSEUDO_PREFIX. But maybe not everyone agrees.
>
> On 19.01.2018 17:00, Volker Vogelhuber wrote:
>>
>> I'm currently trying to create a multi RootFS WIC image as mentioned in
>> directdisk-multi-rootfs.wks. For that I have two image recipes. One that
>> is creating only an ext4 image (image-recovery), and the second that is also
>> creating a WIC image (image-main). I used the IMAGE_FSTYPES variable for
>> that. The WKS file for the second image is integrating the recovery image by
>> specifying --rootfs-dir=image-recovery in it's part description.
>>
>> # primary / recovery image
>> part / --source rootfs --rootfs-dir=image-main --exclude-path mnt/data/
>> mnt/data2/ --fstype=ext4 --label primary_rootfs --align 1024 --size 700
>> --overhead-factor=1.0
>> part /recovery --source rootfs --rootfs-dir=image-recovery --fstype=ext4
>> --label recovery_rootfs --align 1024 --size 640 --overhead-factor=1.0
>>
>> The UIDs of the second rootfs (image-main) are correctly set to 0 within
>> the file system when calling mkfs.ext4 during prepare_rootfs_ext. For the
>> recovery rootfs the UID is always set to my own (host) one which is of
>> course not valid for the image where that UID does not exist.
>> I tried calling the mkfs.ext4 command myself from a terminal and for
>> whatever reason an image created out of the rootfs folder of the second
>> image (image-main) recipe is deployed with the correct UID 0, while the
>> rootfs folder of the first image (image-recovery) recipe always uses the UID
>> of the source folder/files.
>>
>> I search the code of e2fsprogs for the line that sets the UID and added a
>> printf in set_inode_extra. There I can see clearly that the source UID for
>> the file is 0 for the rootfs of the image-main rootfs folder while it is
>> 1 (my own UID) for the image-recovery. I wonder how the UID of the
>> image-main rootfs folder can be zero when I don't call any command with root
>> permissions. I searched for a preparation step where the UIDs are managed in
>> the scripts folder of Yocto, but didn't found any hint for the whole
>> behavior. So while it is good that the rootfs partition of the main rootfs
>> has the UID set correctly to zero, I can't understand why it happens. On the
>> other side I can understand why the UID of the recovery rootfs is set to my
>> own one, but it stops me from booting that rootfs because the UIDs of the
>> files and folders are set to a user that does not exist on the target
>> system.
>>
>> Can someone please explain to me, how that UID handling is meant to be
>> done?
>
>
> --
>
>
>
>
> * *
>
> *Volker Vogelhuber* | Head of Software Design
>
>
>
> *PENTAX**Medical
> */Excellence in Focus/
>
>
>
> *T:* // +49 (0)821 650566-18  | *F:* +49 (0)821 650566-20
>
>
>
> Hoya Corporation – Pentax Medical Division
>
> *Digital Endoscopy GmbH*
>
> Paul-Lenz-Str. 5
>
> 86316 Friedberg – Germany
>
> pentaxmedical.com
>
>
>
> *Curious*about new *PENTAX*Medical products and activities?
>
> *Follow us*on our Social Media channels!
>
>
>
>   
> 
>
>
>
> Handelsregister HRB 27226
>
> Amtsgericht Augsburg
>
> Geschäftsführer: Michael Drexel, Gerald Bottero
>
> _
>
>
>
> This e-mail may contain confidential and/or privileged information. If
> you are not the intended recipient (or have received this e-mail in
> error) please notify the sender immediately and destroy this e-mail. Any
> unauthorized copying, 

Re: [OE-core] [PATCH 8/9] gcc-7.2: Fix libgfortran build

2017-12-19 Thread Ricardo Ribalda Delgado
Hi Richard

My target is a X86_64 camera, and I have only tried with it.

On Tue, Dec 19, 2017 at 12:08 PM, Richard Purdie
<richard.pur...@linuxfoundation.org> wrote:
> On Tue, 2017-12-12 at 09:23 -0800, Khem Raj wrote:
>> From: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
>>
>> Without this patch libbacktrace cannot be included/link during
>> libgfortran build.
>>
>> libbtool: link: cannot find the library
>> `../libbacktrace/libbacktrace.la'
>> or unhandled argument `../libbacktrace/libbacktrace.la
>>
>> Signed-off-by: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
>> Signed-off-by: Khem Raj <raj.k...@gmail.com>
>> ---
>>  meta/recipes-devtools/gcc/gcc-7.2.inc  |  1 +
>>  .../gcc/gcc-7.2/0051-Fix-gfortran-build.patch  | 53
>> ++
>>  2 files changed, 54 insertions(+)
>>  create mode 100644 meta/recipes-devtools/gcc/gcc-7.2/0051-Fix-
>> gfortran-build.patch
>>
>> diff --git a/meta/recipes-devtools/gcc/gcc-7.2.inc b/meta/recipes-
>> devtools/gcc/gcc-7.2.inc
>> index 1d40cba731..baf98aeba8 100644
>> --- a/meta/recipes-devtools/gcc/gcc-7.2.inc
>> +++ b/meta/recipes-devtools/gcc/gcc-7.2.inc
>> @@ -75,6 +75,7 @@ SRC_URI = "\
>> file://0048-gcc-Enable-static-PIE.patch \
>> file://fix-segmentation-fault-precompiled-hdr.patch \
>> file://0050-RISC-V-Handle-non-legitimate-address-in-
>> riscv_legiti.patch \
>> +   file://0051-Fix-gfortran-build.patch \
>> ${BACKPORTS} \
>>  "
>>  BACKPORTS = "\
>> diff --git a/meta/recipes-devtools/gcc/gcc-7.2/0051-Fix-gfortran-
>> build.patch b/meta/recipes-devtools/gcc/gcc-7.2/0051-Fix-gfortran-
>> build.patch
>> new file mode 100644
>> index 00..a71b6b0bee
>> --- /dev/null
>> +++ b/meta/recipes-devtools/gcc/gcc-7.2/0051-Fix-gfortran-build.patch
>> @@ -0,0 +1,53 @@
>> +Without this patch libbacktrace cannot be included/link during
>> +libgfortran build.
>> +
>> +libbtool: link: cannot find the library
>> `../libbacktrace/libbacktrace.la'
>> +or unhandled argument `../libbacktrace/libbacktrace.la'
>> +
>> +Upstream-Status: Inappropriate [OE specific]
>> +Signed-off-by: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
>> +
>> +diff --git a/libgfortran/Makefile.am b/libgfortran/Makefile.am
>> +index 2857af5943f9..e07760069a3c 100644
>> +--- a/libgfortran/Makefile.am
>>  b/libgfortran/Makefile.am
>> +@@ -37,7 +37,7 @@ toolexeclib_LTLIBRARIES = libgfortran.la
>> + toolexeclib_DATA = libgfortran.spec
>> + libgfortran_la_LINK = $(LINK) $(libgfortran_la_LDFLAGS)
>> + libgfortran_la_LDFLAGS = -version-info `grep -v '^\#'
>> $(srcdir)/libtool-version` \
>> +-$(LTLDFLAGS) $(LIBQUADLIB) ../libbacktrace/libbacktrace.la
>> \
>> ++$(LTLDFLAGS) $(LIBQUADLIB)
>> ../../libbacktrace/libbacktrace.la \
>> + $(HWCAP_LDFLAGS) \
>> + -lm $(extra_ldflags_libgfortran) \
>> + $(version_arg) -Wc,-shared-libgcc
>> +@@ -64,7 +64,7 @@ AM_CPPFLAGS = -iquote$(srcdir)/io
>> -I$(srcdir)/$(MULTISRCTOP)../gcc \
>> +   -I$(MULTIBUILDTOP)../libgcc \
>> +   -I$(srcdir)/$(MULTISRCTOP)../libbacktrace \
>> +   -I$(MULTIBUILDTOP)../libbacktrace \
>> +-  -I../libbacktrace
>> ++  -I../../libbacktrace
>> +
>> + # Fortran rules for complex multiplication and division
>> + AM_CFLAGS += -fcx-fortran-rules
>> +diff --git a/libgfortran/Makefile.in b/libgfortran/Makefile.in
>> +index 05b183dcadb0..c9e0280e412c 100644
>> +--- a/libgfortran/Makefile.in
>>  b/libgfortran/Makefile.in
>> +@@ -581,7 +581,7 @@ toolexeclib_LTLIBRARIES = libgfortran.la
>> + toolexeclib_DATA = libgfortran.spec
>> + libgfortran_la_LINK = $(LINK) $(libgfortran_la_LDFLAGS)
>> + libgfortran_la_LDFLAGS = -version-info `grep -v '^\#'
>> $(srcdir)/libtool-version` \
>> +-$(LTLDFLAGS) $(LIBQUADLIB) ../libbacktrace/libbacktrace.la
>> \
>> ++$(LTLDFLAGS) $(LIBQUADLIB)
>> ../../libbacktrace/libbacktrace.la \
>> + $(HWCAP_LDFLAGS) \
>> + -lm $(extra_ldflags_libgfortran) \
>> + $(version_arg) -Wc,-shared-libgcc
>> +@@ -602,7 +602,7 @@ AM_CPPFLAGS = -iquote$(srcdir)/io
>> -I$(srcdir)/$(MULTISRCTOP)../gcc \
>> +   -I$(MULTIBUILDTOP)../libgcc \
>> +   -I$(srcdir)/$(MULTISRCTOP)../libbacktrace \
>> +   -I$(MULTIBUILDTOP)../libbacktrace \
>> +-  -I../libbacktrace
>> ++  -I../../libbacktrace
>> +
>> + gfor_io_src = io/size_from_kind.c $(am__append_2)
>> + gfor_io_headers = \
>
> Did you try this for something other than x86_64? I think this won't
> work when cross compiling and host != target.
>
> I do have a better fix which might work in mind...
>
> Cheers,
>
> Richard
>



-- 
Ricardo Ribalda
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH v2] meson: Port pkgconfig-native patch to 0.43.0

2017-12-18 Thread Ricardo Ribalda Delgado
Hello

On Fri, Dec 15, 2017 at 4:54 PM, Alexander Kanavin
<alexander.kana...@linux.intel.com> wrote:
> On 12/15/2017 05:50 PM, Ricardo Ribalda Delgado wrote:
>
>>> Unfortunately, the same patch needs to be ported again to 0.44.0, as the
>>> changes upstream made are non-trivial. Can you do that please?
>>
>>
>> Sure,
>>
>> can you wait til monday? I have all my test tools setup in the office
>
>
> Yes, sure. In a moment I'll publish a new patchset that introduces meson
> 0.44 and drops your previous 0.43-compatible version of the patch, and then
> you can rebase on top of that and send to the list.
Sent

Feel free to include it to your patchset if you need a v6

Regards!

>
> Going forward, maybe you should convince upstream to take it after all...

:), sure

>
> Alex



-- 
Ricardo Ribalda
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] meson: Port pkgconfig-native patch to 0.44.0

2017-12-18 Thread Ricardo Ribalda Delgado
The update to 0.44.0 did not add this patch required for qt builds.

Signed-off-by: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
---
This patch sits on top of  Alexander Kanavin's "Introduce meson build
system v5" patchset.

 .../meson/meson/0003-native_bindir.patch   | 109 +
 meta/recipes-devtools/meson/meson_0.44.0.bb|   1 +
 2 files changed, 110 insertions(+)
 create mode 100644 meta/recipes-devtools/meson/meson/0003-native_bindir.patch

diff --git a/meta/recipes-devtools/meson/meson/0003-native_bindir.patch 
b/meta/recipes-devtools/meson/meson/0003-native_bindir.patch
new file mode 100644
index ..8911dd6b34e1
--- /dev/null
+++ b/meta/recipes-devtools/meson/meson/0003-native_bindir.patch
@@ -0,0 +1,109 @@
+From: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
+Date: Wed, 15 Nov 2017 15:05:01 +0100
+Subject: [PATCH] native_bindir
+
+Some libraries, like QT, have pre-processors that convert their input
+files into something that the cross-compiler can process. We find the
+path of those pre-processors via pkg-config-native instead of
+pkg-config.
+
+This path forces the use of pkg-config-native for host_bins arguments.
+
+There are some discussions upstream to merge this patch, but I presonaly 
believe
+that is is OE only. 
https://github.com/mesonbuild/meson/issues/1849#issuecomment-303730323
+
+Upstream-Status: Inappropriate [OE specific]
+Signed-off-by: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
+---
+ mesonbuild/dependencies/base.py | 14 +-
+ mesonbuild/dependencies/ui.py   |  6 +++---
+ 2 files changed, 12 insertions(+), 8 deletions(-)
+
+diff --git a/mesonbuild/dependencies/base.py b/mesonbuild/dependencies/base.py
+index 0ef33722f196..b3f7e7c06822 100644
+--- a/mesonbuild/dependencies/base.py
 b/mesonbuild/dependencies/base.py
+@@ -130,7 +130,7 @@ class Dependency:
+ def need_threads(self):
+ return False
+ 
+-def get_pkgconfig_variable(self, variable_name, kwargs):
++def get_pkgconfig_variable(self, variable_name, kwargs, use_native=False):
+ raise DependencyException('{!r} is not a pkgconfig 
dependency'.format(self.name))
+ 
+ def get_configtool_variable(self, variable_name):
+@@ -149,7 +149,7 @@ class InternalDependency(Dependency):
+ self.sources = sources
+ self.ext_deps = ext_deps
+ 
+-def get_pkgconfig_variable(self, variable_name, kwargs):
++def get_pkgconfig_variable(self, variable_name, kwargs, use_native=False):
+ raise DependencyException('Method "get_pkgconfig_variable()" is '
+   'invalid for an internal dependency')
+ 
+@@ -414,10 +414,14 @@ class PkgConfigDependency(ExternalDependency):
+ return s.format(self.__class__.__name__, self.name, self.is_found,
+ self.version_reqs)
+ 
+-def _call_pkgbin(self, args, env=None):
++def _call_pkgbin(self, args, env=None, use_native=False):
+ if not env:
+ env = os.environ
+-p, out = Popen_safe([self.pkgbin] + args, env=env)[0:2]
++if use_native:
++pkgbin = [self.pkgbin + "-native"]
++else:
++pkgbin = [self.pkgbin]
++p, out = Popen_safe(pkgbin + args, env=env)[0:2]
+ return p.returncode, out.strip()
+ 
+ def _convert_mingw_paths(self, args):
+@@ -499,7 +503,7 @@ class PkgConfigDependency(ExternalDependency):
+ self.is_libtool = True
+ self.link_args.append(lib)
+ 
+-def get_pkgconfig_variable(self, variable_name, kwargs):
++def get_pkgconfig_variable(self, variable_name, kwargs, use_native=False):
+ options = ['--variable=' + variable_name, self.name]
+ 
+ if 'define_variable' in kwargs:
+@@ -512,7 +516,7 @@ class PkgConfigDependency(ExternalDependency):
+ 
+ options = ['--define-variable=' + '='.join(definition)] + options
+ 
+-ret, out = self._call_pkgbin(options)
++ret, out = self._call_pkgbin(options, use_native=use_native)
+ variable = ''
+ if ret != 0:
+ if self.required:
+diff --git a/mesonbuild/dependencies/ui.py b/mesonbuild/dependencies/ui.py
+index 1db518c12477..4ed1d041f6f4 100644
+--- a/mesonbuild/dependencies/ui.py
 b/mesonbuild/dependencies/ui.py
+@@ -239,7 +239,7 @@ class QtBaseDependency(ExternalDependency):
+ self.bindir = self.get_pkgconfig_host_bins(core)
+ if not self.bindir:
+ # If exec_prefix is not defined, the pkg-config file is broken
+-prefix = core.get_pkgconfig_variable('exec_prefix', {})
++prefix = core.get_pkgconfig_variable('exec_prefix', {}, 
use_native=True)
+ if prefix:
+ self.bindir = os.path.join(prefix, 'bin')
+ 
+@@ -359,7 +359,7 @@ class Qt4Dependency(QtBaseDependency):
+ applications = ['moc', 'uic', 'rcc', 'lupdate', 'lrelease']
+ fo

Re: [OE-core] [PATCH v2] meson: Port pkgconfig-native patch to 0.43.0

2017-12-15 Thread Ricardo Ribalda Delgado
On Fri, Dec 15, 2017 at 4:27 PM, Alexander Kanavin
<alexander.kana...@linux.intel.com> wrote:
> On 11/16/2017 07:57 PM, Ricardo Ribalda Delgado wrote:
>
>>>> +Some libraries, like QT, have pre-processors that convert their input
>>>> +files into something that the cross-compiler can process. We find the
>>>> +path of those pre-processors via pkg-config-native instead of
>>>> +pkg-config.
>>>> +
>>>> +This path forces the use of pkg-config-native for host_bins arguments.
>>>> +
>>>> +There are some discussions upstream to merge this patch, but I
>>>> presonaly
>>>> believe
>>>> +that is is OE only.
>>>> https://github.com/mesonbuild/meson/issues/1849#issuecomment-303730323
>>>
>>>
>>>
>>> Does the snippet from Martin's patch that I just commented on solve this
>>> issue in a much simpler way?
>>
>>
>> I am afraid not. We need to call pkg-config for getting the -libs
>> -cflags, et all, and pkg-config-native for --host_bins We cannot use
>> the same pkg-config for all unfortunatelly.
>
>
> Unfortunately, the same patch needs to be ported again to 0.44.0, as the
> changes upstream made are non-trivial. Can you do that please?

Sure,

can you wait til monday? I have all my test tools setup in the office

>
> Alex



-- 
Ricardo Ribalda
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH v2] meson: Port pkgconfig-native patch to 0.43.0

2017-11-16 Thread Ricardo Ribalda Delgado
On Thu, Nov 16, 2017 at 6:54 PM, Alexander Kanavin
<alexander.kana...@linux.intel.com> wrote:
> On 11/16/2017 07:45 PM, Ricardo Ribalda Delgado wrote:
>>
>> +Some libraries, like QT, have pre-processors that convert their input
>> +files into something that the cross-compiler can process. We find the
>> +path of those pre-processors via pkg-config-native instead of
>> +pkg-config.
>> +
>> +This path forces the use of pkg-config-native for host_bins arguments.
>> +
>> +There are some discussions upstream to merge this patch, but I presonaly
>> believe
>> +that is is OE only.
>> https://github.com/mesonbuild/meson/issues/1849#issuecomment-303730323
>
>
> Does the snippet from Martin's patch that I just commented on solve this
> issue in a much simpler way?

I am afraid not. We need to call pkg-config for getting the -libs
-cflags, et all, and pkg-config-native for --host_bins We cannot use
the same pkg-config for all unfortunatelly.

>
> Alex



-- 
Ricardo Ribalda
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH v2] meson: Port pkgconfig-native patch to 0.43.0

2017-11-16 Thread Ricardo Ribalda Delgado
The update to 0.43.0 forgot to add this patch required for qt builds.

Signed-off-by: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
---
This patch sits on top of  Alexander Kanavin's "Introduce meson build
system" patchset.

 .../meson/meson/0003-native_bindir.patch   | 95 ++
 meta/recipes-devtools/meson/meson_0.43.0.bb|  1 +
 2 files changed, 96 insertions(+)
 create mode 100644 meta/recipes-devtools/meson/meson/0003-native_bindir.patch

diff --git a/meta/recipes-devtools/meson/meson/0003-native_bindir.patch 
b/meta/recipes-devtools/meson/meson/0003-native_bindir.patch
new file mode 100644
index ..1df1536a7228
--- /dev/null
+++ b/meta/recipes-devtools/meson/meson/0003-native_bindir.patch
@@ -0,0 +1,95 @@
+From 01dd18c9c9c042268b87d576624c16fc74253cd9 Mon Sep 17 00:00:00 2001
+From: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
+Date: Wed, 15 Nov 2017 15:05:01 +0100
+Subject: [PATCH] native_bindir
+
+Some libraries, like QT, have pre-processors that convert their input
+files into something that the cross-compiler can process. We find the
+path of those pre-processors via pkg-config-native instead of
+pkg-config.
+
+This path forces the use of pkg-config-native for host_bins arguments.
+
+There are some discussions upstream to merge this patch, but I presonaly 
believe
+that is is OE only. 
https://github.com/mesonbuild/meson/issues/1849#issuecomment-303730323
+
+Upstream-Status: Inappropriate [OE specific]
+Signed-off-by: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
+---
+ mesonbuild/dependencies/base.py | 14 +-
+ mesonbuild/dependencies/ui.py   |  6 +++---
+ 2 files changed, 12 insertions(+), 8 deletions(-)
+
+diff --git a/mesonbuild/dependencies/base.py b/mesonbuild/dependencies/base.py
+index 0d9742d426cb..0c8e79a8e9e3 100644
+--- a/mesonbuild/dependencies/base.py
 b/mesonbuild/dependencies/base.py
+@@ -114,7 +114,7 @@ class Dependency:
+ def need_threads(self):
+ return False
+ 
+-def get_pkgconfig_variable(self, variable_name):
++def get_pkgconfig_variable(self, variable_name, use_native=False):
+ raise NotImplementedError('{!r} is not a pkgconfig 
dependency'.format(self.name))
+ 
+ 
+@@ -256,8 +256,12 @@ class PkgConfigDependency(ExternalDependency):
+ return s.format(self.__class__.__name__, self.name, self.is_found,
+ self.version_reqs)
+ 
+-def _call_pkgbin(self, args):
+-p, out = Popen_safe([self.pkgbin] + args, env=os.environ)[0:2]
++def _call_pkgbin(self, args, use_native=False):
++if use_native:
++pkgbin = [self.pkgbin + "-native"]
++else:
++pkgbin = [self.pkgbin]
++p, out = Popen_safe(pkgbin + args, env=os.environ)[0:2]
+ return p.returncode, out.strip()
+ 
+ def _set_cargs(self):
+@@ -291,8 +295,8 @@ class PkgConfigDependency(ExternalDependency):
+ self.is_libtool = True
+ self.link_args.append(lib)
+ 
+-def get_pkgconfig_variable(self, variable_name):
+-ret, out = self._call_pkgbin(['--variable=' + variable_name, 
self.name])
++def get_pkgconfig_variable(self, variable_name, use_native=False):
++ret, out = self._call_pkgbin(['--variable=' + variable_name, 
self.name], use_native=use_native)
+ variable = ''
+ if ret != 0:
+ if self.required:
+diff --git a/mesonbuild/dependencies/ui.py b/mesonbuild/dependencies/ui.py
+index 8f183e54d4d2..34ef33e79ad9 100644
+--- a/mesonbuild/dependencies/ui.py
 b/mesonbuild/dependencies/ui.py
+@@ -239,7 +239,7 @@ class QtBaseDependency(ExternalDependency):
+ self.bindir = self.get_pkgconfig_host_bins(core)
+ if not self.bindir:
+ # If exec_prefix is not defined, the pkg-config file is broken
+-prefix = core.get_pkgconfig_variable('exec_prefix')
++prefix = core.get_pkgconfig_variable('exec_prefix', 
use_native=True)
+ if prefix:
+ self.bindir = os.path.join(prefix, 'bin')
+ 
+@@ -359,7 +359,7 @@ class Qt4Dependency(QtBaseDependency):
+ applications = ['moc', 'uic', 'rcc', 'lupdate', 'lrelease']
+ for application in applications:
+ try:
+-return 
os.path.dirname(core.get_pkgconfig_variable('%s_location' % application))
++return 
os.path.dirname(core.get_pkgconfig_variable('%s_location' % application, 
use_native=True))
+ except MesonException:
+ pass
+ 
+@@ -369,7 +369,7 @@ class Qt5Dependency(QtBaseDependency):
+ QtBaseDependency.__init__(self, 'qt5', env, kwargs)
+ 
+ def get_pkgconfig_host_bins(self, core):
+-return core.get_pkgconfig_variable('host_bins')
++return core.get_pkgconfig_variable('host_bins', use_native=True)
+ 
+ 
+ # There are three different ways of depending on SDL2:
+-- 
+2.15.0
+
diff --git a/meta/recipes-

[OE-core] [PATCH] meson: Port pkgconfig-native patch to 0.43.0

2017-11-16 Thread Ricardo Ribalda Delgado
The update to 0.43.0 forgot to add this patch required for qt builds

Signed-off-by: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
---
This patch sits on top of  Alexander Kanavin's "Introduce meson build
system" patchset

 .../meson/meson/0003-native_bindir.patch   | 88 ++
 meta/recipes-devtools/meson/meson_0.43.0.bb|  1 +
 2 files changed, 89 insertions(+)
 create mode 100644 meta/recipes-devtools/meson/meson/0003-native_bindir.patch

diff --git a/meta/recipes-devtools/meson/meson/0003-native_bindir.patch 
b/meta/recipes-devtools/meson/meson/0003-native_bindir.patch
new file mode 100644
index ..805c1f6a50dc
--- /dev/null
+++ b/meta/recipes-devtools/meson/meson/0003-native_bindir.patch
@@ -0,0 +1,88 @@
+From 01dd18c9c9c042268b87d576624c16fc74253cd9 Mon Sep 17 00:00:00 2001
+From: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
+Date: Wed, 15 Nov 2017 15:05:01 +0100
+Subject: [PATCH] native_bindir
+
+There are some discussions upstream to merge this patch, but I presonaly 
believe
+that is is OE only. 
https://github.com/mesonbuild/meson/issues/1849#issuecomment-303730323
+
+Upstream-Status: Inappropriate [OE specific]
+Signed-off-by: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
+---
+ mesonbuild/dependencies/base.py | 14 +-
+ mesonbuild/dependencies/ui.py   |  6 +++---
+ 2 files changed, 12 insertions(+), 8 deletions(-)
+
+diff --git a/mesonbuild/dependencies/base.py b/mesonbuild/dependencies/base.py
+index 0d9742d426cb..0c8e79a8e9e3 100644
+--- a/mesonbuild/dependencies/base.py
 b/mesonbuild/dependencies/base.py
+@@ -114,7 +114,7 @@ class Dependency:
+ def need_threads(self):
+ return False
+ 
+-def get_pkgconfig_variable(self, variable_name):
++def get_pkgconfig_variable(self, variable_name, use_native=False):
+ raise NotImplementedError('{!r} is not a pkgconfig 
dependency'.format(self.name))
+ 
+ 
+@@ -256,8 +256,12 @@ class PkgConfigDependency(ExternalDependency):
+ return s.format(self.__class__.__name__, self.name, self.is_found,
+ self.version_reqs)
+ 
+-def _call_pkgbin(self, args):
+-p, out = Popen_safe([self.pkgbin] + args, env=os.environ)[0:2]
++def _call_pkgbin(self, args, use_native=False):
++if use_native:
++pkgbin = [self.pkgbin + "-native"]
++else:
++pkgbin = [self.pkgbin]
++p, out = Popen_safe(pkgbin + args, env=os.environ)[0:2]
+ return p.returncode, out.strip()
+ 
+ def _set_cargs(self):
+@@ -291,8 +295,8 @@ class PkgConfigDependency(ExternalDependency):
+ self.is_libtool = True
+ self.link_args.append(lib)
+ 
+-def get_pkgconfig_variable(self, variable_name):
+-ret, out = self._call_pkgbin(['--variable=' + variable_name, 
self.name])
++def get_pkgconfig_variable(self, variable_name, use_native=False):
++ret, out = self._call_pkgbin(['--variable=' + variable_name, 
self.name], use_native=use_native)
+ variable = ''
+ if ret != 0:
+ if self.required:
+diff --git a/mesonbuild/dependencies/ui.py b/mesonbuild/dependencies/ui.py
+index 8f183e54d4d2..34ef33e79ad9 100644
+--- a/mesonbuild/dependencies/ui.py
 b/mesonbuild/dependencies/ui.py
+@@ -239,7 +239,7 @@ class QtBaseDependency(ExternalDependency):
+ self.bindir = self.get_pkgconfig_host_bins(core)
+ if not self.bindir:
+ # If exec_prefix is not defined, the pkg-config file is broken
+-prefix = core.get_pkgconfig_variable('exec_prefix')
++prefix = core.get_pkgconfig_variable('exec_prefix', 
use_native=True)
+ if prefix:
+ self.bindir = os.path.join(prefix, 'bin')
+ 
+@@ -359,7 +359,7 @@ class Qt4Dependency(QtBaseDependency):
+ applications = ['moc', 'uic', 'rcc', 'lupdate', 'lrelease']
+ for application in applications:
+ try:
+-return 
os.path.dirname(core.get_pkgconfig_variable('%s_location' % application))
++return 
os.path.dirname(core.get_pkgconfig_variable('%s_location' % application, 
use_native=True))
+ except MesonException:
+ pass
+ 
+@@ -369,7 +369,7 @@ class Qt5Dependency(QtBaseDependency):
+ QtBaseDependency.__init__(self, 'qt5', env, kwargs)
+ 
+ def get_pkgconfig_host_bins(self, core):
+-return core.get_pkgconfig_variable('host_bins')
++return core.get_pkgconfig_variable('host_bins', use_native=True)
+ 
+ 
+ # There are three different ways of depending on SDL2:
+-- 
+2.15.0
+
diff --git a/meta/recipes-devtools/meson/meson_0.43.0.bb 
b/meta/recipes-devtools/meson/meson_0.43.0.bb
index bbb48d9197c0..403f744c1cf5 100644
--- a/meta/recipes-devtools/meson/meson_0.43.0.bb
+++ b/meta/recipes-devtools/meson/meson_0.43.0.bb
@@ -7,6 +7,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=3b83ef963

[OE-core] [meta-oe][PATCH v2 1/2] gcc-6.4: Fix libgfortran build

2017-11-15 Thread Ricardo Ribalda Delgado
Without this patch libbacktrace cannot be included/link during
libgfortran build.

libbtool: link: cannot find the library `../libbacktrace/libbacktrace.la'
or unhandled argument `../libbacktrace/libbacktrace.la'

Signed-off-by: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
---
 meta/recipes-devtools/gcc/gcc-6.4.inc  |  1 +
 .../gcc/gcc-6.4/0057-Fix-gfortran-build.patch  | 53 ++
 2 files changed, 54 insertions(+)
 create mode 100644 
meta/recipes-devtools/gcc/gcc-6.4/0057-Fix-gfortran-build.patch

diff --git a/meta/recipes-devtools/gcc/gcc-6.4.inc 
b/meta/recipes-devtools/gcc/gcc-6.4.inc
index 37e996afb706..f2b01699f157 100644
--- a/meta/recipes-devtools/gcc/gcc-6.4.inc
+++ b/meta/recipes-devtools/gcc/gcc-6.4.inc
@@ -76,6 +76,7 @@ SRC_URI = "\
file://0054_all_nopie-all-flags.patch \
file://0055-unwind_h-glibc26.patch \

file://0056-LRA-PR70904-relax-the-restriction-on-subreg-reload-f.patch \
+   file://0057-Fix-gfortran-build.patch \
${BACKPORTS} \
 "
 BACKPORTS = "\
diff --git a/meta/recipes-devtools/gcc/gcc-6.4/0057-Fix-gfortran-build.patch 
b/meta/recipes-devtools/gcc/gcc-6.4/0057-Fix-gfortran-build.patch
new file mode 100644
index ..30b135b9780f
--- /dev/null
+++ b/meta/recipes-devtools/gcc/gcc-6.4/0057-Fix-gfortran-build.patch
@@ -0,0 +1,53 @@
+Without this patch libbacktrace cannot be included/link during
+libgfortran build.
+
+libbtool: link: cannot find the library `../libbacktrace/libbacktrace.la'
+or unhandled argument `../libbacktrace/libbacktrace.la'
+
+Upstream-Status: Inappropriate [OE specific]
+Signed-off-by: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
+
+diff --git a/libgfortran/Makefile.am b/libgfortran/Makefile.am
+index 39d3e11d223c..b5efe6dfe195 100644
+--- a/libgfortran/Makefile.am
 b/libgfortran/Makefile.am
+@@ -37,7 +37,7 @@ toolexeclib_LTLIBRARIES = libgfortran.la
+ toolexeclib_DATA = libgfortran.spec
+ libgfortran_la_LINK = $(LINK) $(libgfortran_la_LDFLAGS)
+ libgfortran_la_LDFLAGS = -version-info `grep -v '^\#' 
$(srcdir)/libtool-version` \
+-  $(LTLDFLAGS) $(LIBQUADLIB) ../libbacktrace/libbacktrace.la \
++  $(LTLDFLAGS) $(LIBQUADLIB) ../../libbacktrace/libbacktrace.la \
+   -lm $(extra_ldflags_libgfortran) \
+   $(version_arg) -Wc,-shared-libgcc
+ libgfortran_la_DEPENDENCIES = $(version_dep) libgfortran.spec 
$(LIBQUADLIB_DEP)
+@@ -63,7 +63,7 @@ AM_CPPFLAGS = -iquote$(srcdir)/io 
-I$(srcdir)/$(MULTISRCTOP)../gcc \
+ -I$(MULTIBUILDTOP)../libgcc \
+ -I$(srcdir)/$(MULTISRCTOP)../libbacktrace \
+ -I$(MULTIBUILDTOP)../libbacktrace \
+--I../libbacktrace
++-I../../libbacktrace
+ 
+ # Fortran rules for complex multiplication and division
+ AM_CFLAGS += -fcx-fortran-rules
+diff --git a/libgfortran/Makefile.in b/libgfortran/Makefile.in
+index 7ed080cf7b0d..d197fbd6b683 100644
+--- a/libgfortran/Makefile.in
 b/libgfortran/Makefile.in
+@@ -598,7 +598,7 @@ toolexeclib_LTLIBRARIES = libgfortran.la
+ toolexeclib_DATA = libgfortran.spec
+ libgfortran_la_LINK = $(LINK) $(libgfortran_la_LDFLAGS)
+ libgfortran_la_LDFLAGS = -version-info `grep -v '^\#' 
$(srcdir)/libtool-version` \
+-  $(LTLDFLAGS) $(LIBQUADLIB) ../libbacktrace/libbacktrace.la \
++  $(LTLDFLAGS) $(LIBQUADLIB) ../../libbacktrace/libbacktrace.la \
+   -lm $(extra_ldflags_libgfortran) \
+   $(version_arg) -Wc,-shared-libgcc
+ 
+@@ -618,7 +618,7 @@ AM_CPPFLAGS = -iquote$(srcdir)/io 
-I$(srcdir)/$(MULTISRCTOP)../gcc \
+ -I$(MULTIBUILDTOP)../libgcc \
+ -I$(srcdir)/$(MULTISRCTOP)../libbacktrace \
+ -I$(MULTIBUILDTOP)../libbacktrace \
+--I../libbacktrace
++-I../../libbacktrace
+ 
+ gfor_io_src = io/size_from_kind.c $(am__append_2)
+ gfor_io_headers = \
-- 
2.15.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [meta-oe][PATCH v2 2/2] gcc-7.2: Fix libgfortran build

2017-11-15 Thread Ricardo Ribalda Delgado
Without this patch libbacktrace cannot be included/link during
libgfortran build.

libbtool: link: cannot find the library
`../libbacktrace/libbacktrace.la'
or unhandled argument `../libbacktrace/libbacktrace.la

Signed-off-by: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
---
 meta/recipes-devtools/gcc/gcc-7.2.inc  |  1 +
 .../gcc/gcc-7.2/0051-Fix-gfortran-build.patch  | 53 ++
 2 files changed, 54 insertions(+)
 create mode 100644 
meta/recipes-devtools/gcc/gcc-7.2/0051-Fix-gfortran-build.patch

diff --git a/meta/recipes-devtools/gcc/gcc-7.2.inc 
b/meta/recipes-devtools/gcc/gcc-7.2.inc
index 1d40cba73175..ae3ed02d6ce3 100644
--- a/meta/recipes-devtools/gcc/gcc-7.2.inc
+++ b/meta/recipes-devtools/gcc/gcc-7.2.inc
@@ -75,6 +75,7 @@ SRC_URI = "\
file://0048-gcc-Enable-static-PIE.patch \
file://fix-segmentation-fault-precompiled-hdr.patch \

file://0050-RISC-V-Handle-non-legitimate-address-in-riscv_legiti.patch \
+  file://0051-Fix-gfortran-build.patch \
${BACKPORTS} \
 "
 BACKPORTS = "\
diff --git a/meta/recipes-devtools/gcc/gcc-7.2/0051-Fix-gfortran-build.patch 
b/meta/recipes-devtools/gcc/gcc-7.2/0051-Fix-gfortran-build.patch
new file mode 100644
index ..a71b6b0bee0e
--- /dev/null
+++ b/meta/recipes-devtools/gcc/gcc-7.2/0051-Fix-gfortran-build.patch
@@ -0,0 +1,53 @@
+Without this patch libbacktrace cannot be included/link during
+libgfortran build.
+
+libbtool: link: cannot find the library `../libbacktrace/libbacktrace.la'
+or unhandled argument `../libbacktrace/libbacktrace.la'
+
+Upstream-Status: Inappropriate [OE specific]
+Signed-off-by: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
+
+diff --git a/libgfortran/Makefile.am b/libgfortran/Makefile.am
+index 2857af5943f9..e07760069a3c 100644
+--- a/libgfortran/Makefile.am
 b/libgfortran/Makefile.am
+@@ -37,7 +37,7 @@ toolexeclib_LTLIBRARIES = libgfortran.la
+ toolexeclib_DATA = libgfortran.spec
+ libgfortran_la_LINK = $(LINK) $(libgfortran_la_LDFLAGS)
+ libgfortran_la_LDFLAGS = -version-info `grep -v '^\#' 
$(srcdir)/libtool-version` \
+-  $(LTLDFLAGS) $(LIBQUADLIB) ../libbacktrace/libbacktrace.la \
++  $(LTLDFLAGS) $(LIBQUADLIB) ../../libbacktrace/libbacktrace.la \
+   $(HWCAP_LDFLAGS) \
+   -lm $(extra_ldflags_libgfortran) \
+   $(version_arg) -Wc,-shared-libgcc
+@@ -64,7 +64,7 @@ AM_CPPFLAGS = -iquote$(srcdir)/io 
-I$(srcdir)/$(MULTISRCTOP)../gcc \
+ -I$(MULTIBUILDTOP)../libgcc \
+ -I$(srcdir)/$(MULTISRCTOP)../libbacktrace \
+ -I$(MULTIBUILDTOP)../libbacktrace \
+--I../libbacktrace
++-I../../libbacktrace
+ 
+ # Fortran rules for complex multiplication and division
+ AM_CFLAGS += -fcx-fortran-rules
+diff --git a/libgfortran/Makefile.in b/libgfortran/Makefile.in
+index 05b183dcadb0..c9e0280e412c 100644
+--- a/libgfortran/Makefile.in
 b/libgfortran/Makefile.in
+@@ -581,7 +581,7 @@ toolexeclib_LTLIBRARIES = libgfortran.la
+ toolexeclib_DATA = libgfortran.spec
+ libgfortran_la_LINK = $(LINK) $(libgfortran_la_LDFLAGS)
+ libgfortran_la_LDFLAGS = -version-info `grep -v '^\#' 
$(srcdir)/libtool-version` \
+-  $(LTLDFLAGS) $(LIBQUADLIB) ../libbacktrace/libbacktrace.la \
++  $(LTLDFLAGS) $(LIBQUADLIB) ../../libbacktrace/libbacktrace.la \
+   $(HWCAP_LDFLAGS) \
+   -lm $(extra_ldflags_libgfortran) \
+   $(version_arg) -Wc,-shared-libgcc
+@@ -602,7 +602,7 @@ AM_CPPFLAGS = -iquote$(srcdir)/io 
-I$(srcdir)/$(MULTISRCTOP)../gcc \
+ -I$(MULTIBUILDTOP)../libgcc \
+ -I$(srcdir)/$(MULTISRCTOP)../libbacktrace \
+ -I$(MULTIBUILDTOP)../libbacktrace \
+--I../libbacktrace
++-I../../libbacktrace
+ 
+ gfor_io_src = io/size_from_kind.c $(am__append_2)
+ gfor_io_headers = \
-- 
2.15.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] gcc-7.2: Fix libgfortran build

2017-11-15 Thread Ricardo Ribalda Delgado
Hello Khem

I already did it on july
https://patchwork.openembedded.org/patch/141497/

but the patch is lost on the internet cracks :)

On Wed, Nov 15, 2017 at 4:35 AM, Khem Raj <raj.k...@gmail.com> wrote:
> On Mon, Nov 13, 2017 at 4:57 AM, Ricardo Ribalda Delgado
> <ricardo.riba...@gmail.com> wrote:
>> Without this patch libbacktrace cannot be included/link during
>> libgfortran build.
>>
>> libbtool: link: cannot find the library
>> `../libbacktrace/libbacktrace.la'
>> or unhandled argument `../libbacktrace/libbacktrace.la
>>
>
> This patch is ok.
> while here, can you please backport this patch to gcc6 as well ?
>
>
>> Signed-off-by: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
>> ---
>>  meta/recipes-devtools/gcc/gcc-7.2.inc  |  1 +
>>  .../gcc/gcc-7.2/0051-Fix-gfortran-build.patch  | 53 
>> ++
>>  2 files changed, 54 insertions(+)
>>  create mode 100644 
>> meta/recipes-devtools/gcc/gcc-7.2/0051-Fix-gfortran-build.patch
>>
>> diff --git a/meta/recipes-devtools/gcc/gcc-7.2.inc 
>> b/meta/recipes-devtools/gcc/gcc-7.2.inc
>> index 1d40cba73175..ae3ed02d6ce3 100644
>> --- a/meta/recipes-devtools/gcc/gcc-7.2.inc
>> +++ b/meta/recipes-devtools/gcc/gcc-7.2.inc
>> @@ -75,6 +75,7 @@ SRC_URI = "\
>> file://0048-gcc-Enable-static-PIE.patch \
>> file://fix-segmentation-fault-precompiled-hdr.patch \
>> 
>> file://0050-RISC-V-Handle-non-legitimate-address-in-riscv_legiti.patch \
>> +  file://0051-Fix-gfortran-build.patch \
>> ${BACKPORTS} \
>>  "
>>  BACKPORTS = "\
>> diff --git a/meta/recipes-devtools/gcc/gcc-7.2/0051-Fix-gfortran-build.patch 
>> b/meta/recipes-devtools/gcc/gcc-7.2/0051-Fix-gfortran-build.patch
>> new file mode 100644
>> index ..a71b6b0bee0e
>> --- /dev/null
>> +++ b/meta/recipes-devtools/gcc/gcc-7.2/0051-Fix-gfortran-build.patch
>> @@ -0,0 +1,53 @@
>> +Without this patch libbacktrace cannot be included/link during
>> +libgfortran build.
>> +
>> +libbtool: link: cannot find the library `../libbacktrace/libbacktrace.la'
>> +or unhandled argument `../libbacktrace/libbacktrace.la'
>> +
>> +Upstream-Status: Inappropriate [OE specific]
>> +Signed-off-by: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
>> +
>> +diff --git a/libgfortran/Makefile.am b/libgfortran/Makefile.am
>> +index 2857af5943f9..e07760069a3c 100644
>> +--- a/libgfortran/Makefile.am
>>  b/libgfortran/Makefile.am
>> +@@ -37,7 +37,7 @@ toolexeclib_LTLIBRARIES = libgfortran.la
>> + toolexeclib_DATA = libgfortran.spec
>> + libgfortran_la_LINK = $(LINK) $(libgfortran_la_LDFLAGS)
>> + libgfortran_la_LDFLAGS = -version-info `grep -v '^\#' 
>> $(srcdir)/libtool-version` \
>> +-  $(LTLDFLAGS) $(LIBQUADLIB) ../libbacktrace/libbacktrace.la \
>> ++  $(LTLDFLAGS) $(LIBQUADLIB) ../../libbacktrace/libbacktrace.la \
>> +   $(HWCAP_LDFLAGS) \
>> +   -lm $(extra_ldflags_libgfortran) \
>> +   $(version_arg) -Wc,-shared-libgcc
>> +@@ -64,7 +64,7 @@ AM_CPPFLAGS = -iquote$(srcdir)/io 
>> -I$(srcdir)/$(MULTISRCTOP)../gcc \
>> + -I$(MULTIBUILDTOP)../libgcc \
>> + -I$(srcdir)/$(MULTISRCTOP)../libbacktrace \
>> + -I$(MULTIBUILDTOP)../libbacktrace \
>> +--I../libbacktrace
>> ++-I../../libbacktrace
>> +
>> + # Fortran rules for complex multiplication and division
>> + AM_CFLAGS += -fcx-fortran-rules
>> +diff --git a/libgfortran/Makefile.in b/libgfortran/Makefile.in
>> +index 05b183dcadb0..c9e0280e412c 100644
>> +--- a/libgfortran/Makefile.in
>>  b/libgfortran/Makefile.in
>> +@@ -581,7 +581,7 @@ toolexeclib_LTLIBRARIES = libgfortran.la
>> + toolexeclib_DATA = libgfortran.spec
>> + libgfortran_la_LINK = $(LINK) $(libgfortran_la_LDFLAGS)
>> + libgfortran_la_LDFLAGS = -version-info `grep -v '^\#' 
>> $(srcdir)/libtool-version` \
>> +-  $(LTLDFLAGS) $(LIBQUADLIB) ../libbacktrace/libbacktrace.la \
>> ++  $(LTLDFLAGS) $(LIBQUADLIB) ../../libbacktrace/libbacktrace.la \
>> +   $(HWCAP_LDFLAGS) \
>> +   -lm $(extra_ldflags_libgfortran) \
>> +   $(version_arg) -Wc,-shared-libgcc
>> +@@ -602,7 +602,7 @@ AM_CPPFLAGS = -iquote$(srcdir)/io 
>> -I$(srcdir)/$(MULTISRCTOP)../gcc \
>> + -I$(MULTIBUILDTOP)../libgcc \
>> + -I$(srcdir)/$(MULTISRCTOP)../libbacktrace \
>> + -I$(MULTIBUILDTOP)../libbacktrace \
>> +--I../libbacktrace
>> ++-I../../libbacktrace
>> +
>> + gfor_io_src = io/size_from_kind.c $(am__append_2)
>> + gfor_io_headers = \
>> --
>> 2.15.0
>>
>> --
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core



-- 
Ricardo Ribalda
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] gcc-7.2: Fix libgfortran build

2017-11-13 Thread Ricardo Ribalda Delgado
Without this patch libbacktrace cannot be included/link during
libgfortran build.

libbtool: link: cannot find the library
`../libbacktrace/libbacktrace.la'
or unhandled argument `../libbacktrace/libbacktrace.la

Signed-off-by: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
---
 meta/recipes-devtools/gcc/gcc-7.2.inc  |  1 +
 .../gcc/gcc-7.2/0051-Fix-gfortran-build.patch  | 53 ++
 2 files changed, 54 insertions(+)
 create mode 100644 
meta/recipes-devtools/gcc/gcc-7.2/0051-Fix-gfortran-build.patch

diff --git a/meta/recipes-devtools/gcc/gcc-7.2.inc 
b/meta/recipes-devtools/gcc/gcc-7.2.inc
index 1d40cba73175..ae3ed02d6ce3 100644
--- a/meta/recipes-devtools/gcc/gcc-7.2.inc
+++ b/meta/recipes-devtools/gcc/gcc-7.2.inc
@@ -75,6 +75,7 @@ SRC_URI = "\
file://0048-gcc-Enable-static-PIE.patch \
file://fix-segmentation-fault-precompiled-hdr.patch \

file://0050-RISC-V-Handle-non-legitimate-address-in-riscv_legiti.patch \
+  file://0051-Fix-gfortran-build.patch \
${BACKPORTS} \
 "
 BACKPORTS = "\
diff --git a/meta/recipes-devtools/gcc/gcc-7.2/0051-Fix-gfortran-build.patch 
b/meta/recipes-devtools/gcc/gcc-7.2/0051-Fix-gfortran-build.patch
new file mode 100644
index ..a71b6b0bee0e
--- /dev/null
+++ b/meta/recipes-devtools/gcc/gcc-7.2/0051-Fix-gfortran-build.patch
@@ -0,0 +1,53 @@
+Without this patch libbacktrace cannot be included/link during
+libgfortran build.
+
+libbtool: link: cannot find the library `../libbacktrace/libbacktrace.la'
+or unhandled argument `../libbacktrace/libbacktrace.la'
+
+Upstream-Status: Inappropriate [OE specific]
+Signed-off-by: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
+
+diff --git a/libgfortran/Makefile.am b/libgfortran/Makefile.am
+index 2857af5943f9..e07760069a3c 100644
+--- a/libgfortran/Makefile.am
 b/libgfortran/Makefile.am
+@@ -37,7 +37,7 @@ toolexeclib_LTLIBRARIES = libgfortran.la
+ toolexeclib_DATA = libgfortran.spec
+ libgfortran_la_LINK = $(LINK) $(libgfortran_la_LDFLAGS)
+ libgfortran_la_LDFLAGS = -version-info `grep -v '^\#' 
$(srcdir)/libtool-version` \
+-  $(LTLDFLAGS) $(LIBQUADLIB) ../libbacktrace/libbacktrace.la \
++  $(LTLDFLAGS) $(LIBQUADLIB) ../../libbacktrace/libbacktrace.la \
+   $(HWCAP_LDFLAGS) \
+   -lm $(extra_ldflags_libgfortran) \
+   $(version_arg) -Wc,-shared-libgcc
+@@ -64,7 +64,7 @@ AM_CPPFLAGS = -iquote$(srcdir)/io 
-I$(srcdir)/$(MULTISRCTOP)../gcc \
+ -I$(MULTIBUILDTOP)../libgcc \
+ -I$(srcdir)/$(MULTISRCTOP)../libbacktrace \
+ -I$(MULTIBUILDTOP)../libbacktrace \
+--I../libbacktrace
++-I../../libbacktrace
+ 
+ # Fortran rules for complex multiplication and division
+ AM_CFLAGS += -fcx-fortran-rules
+diff --git a/libgfortran/Makefile.in b/libgfortran/Makefile.in
+index 05b183dcadb0..c9e0280e412c 100644
+--- a/libgfortran/Makefile.in
 b/libgfortran/Makefile.in
+@@ -581,7 +581,7 @@ toolexeclib_LTLIBRARIES = libgfortran.la
+ toolexeclib_DATA = libgfortran.spec
+ libgfortran_la_LINK = $(LINK) $(libgfortran_la_LDFLAGS)
+ libgfortran_la_LDFLAGS = -version-info `grep -v '^\#' 
$(srcdir)/libtool-version` \
+-  $(LTLDFLAGS) $(LIBQUADLIB) ../libbacktrace/libbacktrace.la \
++  $(LTLDFLAGS) $(LIBQUADLIB) ../../libbacktrace/libbacktrace.la \
+   $(HWCAP_LDFLAGS) \
+   -lm $(extra_ldflags_libgfortran) \
+   $(version_arg) -Wc,-shared-libgcc
+@@ -602,7 +602,7 @@ AM_CPPFLAGS = -iquote$(srcdir)/io 
-I$(srcdir)/$(MULTISRCTOP)../gcc \
+ -I$(MULTIBUILDTOP)../libgcc \
+ -I$(srcdir)/$(MULTISRCTOP)../libbacktrace \
+ -I$(MULTIBUILDTOP)../libbacktrace \
+--I../libbacktrace
++-I../../libbacktrace
+ 
+ gfor_io_src = io/size_from_kind.c $(am__append_2)
+ gfor_io_headers = \
-- 
2.15.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] OpenEmbedded Developer Meeting Oct 22, 2017 in Prague (before ELCE)

2017-09-26 Thread Ricardo Ribalda Delgado
Hi

On Mon, Sep 25, 2017 at 6:23 PM, Jeff Osier-Mixon <je...@jefro.net> wrote:
> It certainly looks interesting! The  main issue is that our table is about
> 0.5 x 1.4 meters, so setting up demos as well as screens and keyboards may
> be a difficult task. I'll do what I can to set up a second table at the
> booth.

I have to bring it anyway. We can postpone the decision.

Regards!

>
> thanks!
>
> On Mon, Sep 25, 2017 at 7:08 AM, Ricardo Ribalda Delgado
> <ricardo.riba...@gmail.com> wrote:
>>
>> Hi
>>
>> On Mon, Sep 25, 2017 at 4:05 PM, Philip Balister <phi...@balister.org>
>> wrote:
>> > On 09/25/2017 10:00 AM, Ricardo Ribalda Delgado wrote:
>> >> If you are looking for a "fun" demo. I plan to show our bottle scanner
>> >> to the ELCE showcase. I could ask my manager if we can leave it on the
>> >> yocto booth during the conference.
>> >>
>> >> We use yocto + our layer https://github.com/qtec/meta-qtec-core
>> >
>> > How large is it? Can you send us a photo?
>>
>> This is the last photo I have from the instrument. You can use the
>> 50cl beer bottle as a reference ;).
>>
>> You also need a screen + keyboard to see the results.
>>
>> >
>> > Philip
>> >
>> >>
>> >> Regards!
>> >>
>> >> On Fri, Sep 22, 2017 at 10:49 PM, Jeff Osier-Mixon <je...@jefro.net>
>> >> wrote:
>> >>> If its relevance to YP and OE is able to be explained, it would be
>> >>> welcomed.
>> >>> The only issue I see is the size of the booth, which is tiny. However,
>> >>> we
>> >>> frequently spill out of our confined space, and I will locate a second
>> >>> table
>> >>> if we end up needing one. Great to see community effort on the demos!
>> >>>
>> >>> On Thu, Sep 21, 2017 at 1:56 PM, Philip Balister <phi...@balister.org>
>> >>> wrote:
>> >>>>
>> >>>> On 09/21/2017 02:32 PM, akuster808 wrote:
>> >>>>>
>> >>>>>
>> >>>>> On 09/21/2017 01:27 PM, Philip Balister wrote:
>> >>>>>> On 09/20/2017 01:50 AM, Mike Looijmans wrote:
>> >>>>>>> On 18-09-17 18:25, Trevor Woerner wrote:
>> >>>>>>>> Hi Mike,
>> >>>>>>>>
>> >>>>>>>> On Mon, Sep 18, 2017 at 8:45 AM, Mike Looijmans
>> >>>>>>>> <mike.looijm...@topic.nl> wrote:
>> >>>>>>>>> I can probably bring some work (e.g. Zynq MPSoC board) and fun
>> >>>>>>>>> (settop box)
>> >>>>>>>>> hardware along to demonstrate what I'm using OE for.
>> >>>>>>>> Any chance you could set something up that could be on display at
>> >>>>>>>> the
>> >>>>>>>> Yocto booth during the conference?
>> >>>>>>> Depends on what I'll be able tug along in my luggage on the
>> >>>>>>> airplane,
>> >>>>>>> but whatever I can bring is probably suited for public display. A
>> >>>>>>> few
>> >>>>>>> circuit boards will certainly fit, so if the stand could provide a
>> >>>>>>> HDMI
>> >>>>>>> monitor (or TV) to connect them to that'd be awesome.
>> >>>>>> I'd love to see some different things on the stand. Make sure you
>> >>>>>> help
>> >>>>>> explain to people why the Yocto Porject and OpenEmbedded are
>> >>>>>> important
>> >>>>>> to you and your product.
>> >>>>> Philip,
>> >>>>>
>> >>>>> Since you are the OE rep to the Yocto Project, can you make sure
>> >>>>> this is
>> >>>>> OK with them. There could be space  or limitations at their booth.
>> >>>>
>> >>>> I mentioned it to Jefro, I'm also making a guess he has something
>> >>>> based
>> >>>> on a Xilinx product, who are members.
>> >>>>
>> >>>> Philip
>> >>>>
>> >>>>>
>> >>>>> Thanks,
>> >>>>> - Armin
>> >>>>>>
>> >>>>>> Philip
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>> M.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Kind regards,
>> >>>>>>>
>> >>>>>>> Mike Looijmans
>> >>>>>>> System Expert
>> >>>>>>>
>> >>>>>>> TOPIC Products
>> >>>>>>> Materiaalweg 4, NL-5681 RJ Best
>> >>>>>>> Postbus 440, NL-5680 AK Best
>> >>>>>>> Telefoon: +31 (0) 499 33 69 79
>> >>>>>>> E-mail: mike.looijm...@topicproducts.com
>> >>>>>>> Website: www.topicproducts.com
>> >>>>>>>
>> >>>>>>> Please consider the environment before printing this e-mail
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Visit us at the Space Tech Expo Europe (Stand E-71)
>> >>>>>>>
>> >>>>>
>> >>>>>
>> >>>> --
>> >>>> ___
>> >>>> Openembedded-core mailing list
>> >>>> Openembedded-core@lists.openembedded.org
>> >>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Jeff Osier-Mixon - Open Source Community Manager, Intel Corporation
>> >>>
>> >>> --
>> >>> ___
>> >>> Openembedded-core mailing list
>> >>> Openembedded-core@lists.openembedded.org
>> >>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>> >>>
>> >>
>> >>
>> >>
>>
>>
>>
>> --
>> Ricardo Ribalda
>
>
>
>
> --
> Jeff Osier-Mixon - Open Source Community Manager, Intel Corporation



-- 
Ricardo Ribalda
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH] bitbake.conf: Add unzip hosttool

2017-07-18 Thread Ricardo Ribalda Delgado
Hi Ross

That did the trick. I have just posted a new patch!

Thanks!

On Tue, Jul 18, 2017 at 12:47 PM, Burton, Ross <ross.bur...@intel.com> wrote:
>
> On 18 July 2017 at 11:03, Ricardo Ribalda Delgado
> <ricardo.riba...@gmail.com> wrote:
>>
>> Unzip is required for jar files. Without this patch:
>> ERROR: junit4-4.3.1-r0 do_unpack: Unpack failure for URL:
>> 'http://downloads.sourceforge.net/junit/junit-4.3.1-src.jar'. Unpack
>> command
>>
>> PATH="/var/lib/jenkins/workspace/qt5122-dyspro/build/tmp/sysroots-uninative/x86_64-linux/usr/bin
>> ..."
>> unzip -q -o '/var/lib/yocto/downloads/junit-4.3.1-src.jar' failed with
>> return value 127
>
>
> Proper fix is to fix the automatic dependency generation.
>
> The bitbake fetcher handles jar files:
>
> elif file.endswith('.zip') or file.endswith('.jar'):
> ...
> cmd = 'unzip -q -o'
>
> But the dependency generation in base.bbclass just handles .zip:
>
> # .zip should DEPEND on unzip-native for unpacking
> elif path.endswith('.zip'):
> d.appendVarFlag('do_unpack', 'depends', '
> unzip-native:do_populate_sysroot')
>
> So the fix is to extend that test in base.bbclass to handle .zip and .jar.
>
> Ross



-- 
Ricardo Ribalda
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] base.bbclass: Make .jar file depend on unzip-native

2017-07-18 Thread Ricardo Ribalda Delgado
Unzip is required for jar files. Without this patch:
ERROR: junit4-4.3.1-r0 do_unpack: Unpack failure for URL:
'http://downloads.sourceforge.net/junit/junit-4.3.1-src.jar'. Unpack
command
PATH="/var/lib/jenkins/workspace/qt5122-dyspro/build/tmp/sysroots-uninative/x86_64-linux/usr/bin
 ..."
unzip -q -o '/var/lib/yocto/downloads/junit-4.3.1-src.jar' failed with
return value 127

Suggested-by: Ross Burton <ross.bur...@intel.com>
Signed-off-by: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
---
 meta/classes/base.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 27a28b8b8c47..4b05d5d4 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -628,7 +628,7 @@ python () {
 d.appendVarFlag('do_unpack', 'depends', ' 
xz-native:do_populate_sysroot')
 
 # .zip should DEPEND on unzip-native for unpacking
-elif path.endswith('.zip'):
+elif path.endswith('.zip') or path.endswith('.jar'):
 d.appendVarFlag('do_unpack', 'depends', ' 
unzip-native:do_populate_sysroot')
 
 # file is needed by rpm2cpio.sh
-- 
2.13.2

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH] bitbake.conf: Add unzip hosttool

2017-07-18 Thread Ricardo Ribalda Delgado
Unzip is required for jar files. Without this patch:
ERROR: junit4-4.3.1-r0 do_unpack: Unpack failure for URL:
'http://downloads.sourceforge.net/junit/junit-4.3.1-src.jar'. Unpack
command
PATH="/var/lib/jenkins/workspace/qt5122-dyspro/build/tmp/sysroots-uninative/x86_64-linux/usr/bin
 ..."
unzip -q -o '/var/lib/yocto/downloads/junit-4.3.1-src.jar' failed with
return value 127

Signed-off-by: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
---
 meta/conf/bitbake.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 9a3aa8bbf29e..35608d0fa787 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -477,7 +477,7 @@ HOSTTOOLS += "ip ping ps scp ssh stty"
 HOSTTOOLS_NONFATAL += "aws ccache gcc-ar gpg ld.bfd ld.gold nc sftp socat sudo"
 
 # Temporary add few more detected in bitbake world
-HOSTTOOLS_NONFATAL += "join nl size yes zcat"
+HOSTTOOLS_NONFATAL += "join nl size unzip yes zcat"
 
 CCACHE ??= ""
 # ccache < 3.1.10 will create CCACHE_DIR on startup even if disabled, and
-- 
2.13.2

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH v3 4/4] gcc-7.1: Fix libgfortran build

2017-07-03 Thread Ricardo Ribalda Delgado
Without this patch libbacktrace cannot be included/link during
libgfortran build.

libbtool: link: cannot find the library
`../libbacktrace/libbacktrace.la'
or unhandled argument `../libbacktrace/libbacktrace.la

Suggested-by: Khem Raj <raj.k...@gmail.com>
Signed-off-by: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
---
 meta/recipes-devtools/gcc/gcc-7.1.inc  |  1 +
 .../gcc/gcc-7.1/0048-Fix-gfortran-build.patch  | 53 ++
 2 files changed, 54 insertions(+)
 create mode 100644 
meta/recipes-devtools/gcc/gcc-7.1/0048-Fix-gfortran-build.patch

diff --git a/meta/recipes-devtools/gcc/gcc-7.1.inc 
b/meta/recipes-devtools/gcc/gcc-7.1.inc
index 4098d6a2c1e0..e142cdf79433 100644
--- a/meta/recipes-devtools/gcc/gcc-7.1.inc
+++ b/meta/recipes-devtools/gcc/gcc-7.1.inc
@@ -72,6 +72,7 @@ SRC_URI = "\
file://0045-Link-libgcc-using-LDFLAGS-not-just-SHLIB_LDFLAGS.patch \

file://0046-libgcc_s-Use-alias-for-__cpu_indicator_init-instead-.patch \
file://0047-sync-gcc-stddef.h-with-musl.patch \
+   file://0048-Fix-gfortran-build.patch \
${BACKPORTS} \
 "
 BACKPORTS = "\
diff --git a/meta/recipes-devtools/gcc/gcc-7.1/0048-Fix-gfortran-build.patch 
b/meta/recipes-devtools/gcc/gcc-7.1/0048-Fix-gfortran-build.patch
new file mode 100644
index ..a71b6b0bee0e
--- /dev/null
+++ b/meta/recipes-devtools/gcc/gcc-7.1/0048-Fix-gfortran-build.patch
@@ -0,0 +1,53 @@
+Without this patch libbacktrace cannot be included/link during
+libgfortran build.
+
+libbtool: link: cannot find the library `../libbacktrace/libbacktrace.la'
+or unhandled argument `../libbacktrace/libbacktrace.la'
+
+Upstream-Status: Inappropriate [OE specific]
+Signed-off-by: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
+
+diff --git a/libgfortran/Makefile.am b/libgfortran/Makefile.am
+index 2857af5943f9..e07760069a3c 100644
+--- a/libgfortran/Makefile.am
 b/libgfortran/Makefile.am
+@@ -37,7 +37,7 @@ toolexeclib_LTLIBRARIES = libgfortran.la
+ toolexeclib_DATA = libgfortran.spec
+ libgfortran_la_LINK = $(LINK) $(libgfortran_la_LDFLAGS)
+ libgfortran_la_LDFLAGS = -version-info `grep -v '^\#' 
$(srcdir)/libtool-version` \
+-  $(LTLDFLAGS) $(LIBQUADLIB) ../libbacktrace/libbacktrace.la \
++  $(LTLDFLAGS) $(LIBQUADLIB) ../../libbacktrace/libbacktrace.la \
+   $(HWCAP_LDFLAGS) \
+   -lm $(extra_ldflags_libgfortran) \
+   $(version_arg) -Wc,-shared-libgcc
+@@ -64,7 +64,7 @@ AM_CPPFLAGS = -iquote$(srcdir)/io 
-I$(srcdir)/$(MULTISRCTOP)../gcc \
+ -I$(MULTIBUILDTOP)../libgcc \
+ -I$(srcdir)/$(MULTISRCTOP)../libbacktrace \
+ -I$(MULTIBUILDTOP)../libbacktrace \
+--I../libbacktrace
++-I../../libbacktrace
+ 
+ # Fortran rules for complex multiplication and division
+ AM_CFLAGS += -fcx-fortran-rules
+diff --git a/libgfortran/Makefile.in b/libgfortran/Makefile.in
+index 05b183dcadb0..c9e0280e412c 100644
+--- a/libgfortran/Makefile.in
 b/libgfortran/Makefile.in
+@@ -581,7 +581,7 @@ toolexeclib_LTLIBRARIES = libgfortran.la
+ toolexeclib_DATA = libgfortran.spec
+ libgfortran_la_LINK = $(LINK) $(libgfortran_la_LDFLAGS)
+ libgfortran_la_LDFLAGS = -version-info `grep -v '^\#' 
$(srcdir)/libtool-version` \
+-  $(LTLDFLAGS) $(LIBQUADLIB) ../libbacktrace/libbacktrace.la \
++  $(LTLDFLAGS) $(LIBQUADLIB) ../../libbacktrace/libbacktrace.la \
+   $(HWCAP_LDFLAGS) \
+   -lm $(extra_ldflags_libgfortran) \
+   $(version_arg) -Wc,-shared-libgcc
+@@ -602,7 +602,7 @@ AM_CPPFLAGS = -iquote$(srcdir)/io 
-I$(srcdir)/$(MULTISRCTOP)../gcc \
+ -I$(MULTIBUILDTOP)../libgcc \
+ -I$(srcdir)/$(MULTISRCTOP)../libbacktrace \
+ -I$(MULTIBUILDTOP)../libbacktrace \
+--I../libbacktrace
++-I../../libbacktrace
+ 
+ gfor_io_src = io/size_from_kind.c $(am__append_2)
+ gfor_io_headers = \
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH v3 3/4] libgfortran: Add missing fincludes

2017-07-03 Thread Ricardo Ribalda Delgado
ERROR: libgfortran-6.3.0-r0 do_package: QA Issue: libgfortran:
Files/directories were installed but not shipped in any package:
/usr/lib/gcc/x86_64-poky-linux/6.3.0/finclude
/usr/lib/gcc/x86_64-poky-linux/6.3.0/finclude/ieee_features.mod
/usr/lib/gcc/x86_64-poky-linux/6.3.0/finclude/ieee_arithmetic.mod
/usr/lib/gcc/x86_64-poky-linux/6.3.0/finclude/ieee_exceptions.mod

Signed-off-by: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
---
 meta/recipes-devtools/gcc/libgfortran.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/gcc/libgfortran.inc 
b/meta/recipes-devtools/gcc/libgfortran.inc
index 3b94c1b85b70..5f5d4af7589d 100644
--- a/meta/recipes-devtools/gcc/libgfortran.inc
+++ b/meta/recipes-devtools/gcc/libgfortran.inc
@@ -54,6 +54,7 @@ FILES_${PN}-dev = "\
 ${libdir}/libgfortran.la \
 ${libdir}/gcc/${TARGET_SYS}/${BINV}/libgfortranbegin.* \
 ${libdir}/gcc/${TARGET_SYS}/${BINV}/libcaf_single* \
+${libdir}/gcc/${TARGET_SYS}/${BINV}/finclude/ \
 "
 FILES_${PN}-staticdev = "${libdir}/libgfortran.a"
 
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH v3 2/4] libgfortran: Add missing dependency gcc-cross

2017-07-03 Thread Ricardo Ribalda Delgado
Due to the fact that the recipe uses INHIBIT_DEFAULT_DEPS, we need to
manually add the cross compiler as a dependency.

Signed-off-by: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
---
 meta/recipes-devtools/gcc/libgfortran.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/gcc/libgfortran.inc 
b/meta/recipes-devtools/gcc/libgfortran.inc
index 4846decbb834..3b94c1b85b70 100644
--- a/meta/recipes-devtools/gcc/libgfortran.inc
+++ b/meta/recipes-devtools/gcc/libgfortran.inc
@@ -37,7 +37,7 @@ do_install () {
 }
 
 INHIBIT_DEFAULT_DEPS = "1"
-DEPENDS = "gcc-runtime"
+DEPENDS = "gcc-runtime gcc-cross-${TARGET_ARCH}"
 
 BBCLASSEXTEND = "nativesdk"
 
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH v3 1/4] gcc-6.3: Fix libgfortran build

2017-07-03 Thread Ricardo Ribalda Delgado
Without this patch libbacktrace cannot be included/link during
libgfortran build.

libbtool: link: cannot find the library `../libbacktrace/libbacktrace.la'
or unhandled argument `../libbacktrace/libbacktrace.la'

Signed-off-by: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
---
 meta/recipes-devtools/gcc/gcc-6.3.inc  |  1 +
 .../gcc/gcc-6.3/0055-Fix-gfortran-build.patch  | 53 ++
 2 files changed, 54 insertions(+)
 create mode 100644 
meta/recipes-devtools/gcc/gcc-6.3/0055-Fix-gfortran-build.patch

diff --git a/meta/recipes-devtools/gcc/gcc-6.3.inc 
b/meta/recipes-devtools/gcc/gcc-6.3.inc
index 86b3e9ff19a4..2595dbd0ee8b 100644
--- a/meta/recipes-devtools/gcc/gcc-6.3.inc
+++ b/meta/recipes-devtools/gcc/gcc-6.3.inc
@@ -74,6 +74,7 @@ SRC_URI = "\

file://0047-libgcc_s-Use-alias-for-__cpu_indicator_init-instead-.patch \
file://0048-sync-gcc-stddef.h-with-musl.patch \
file://0054_all_nopie-all-flags.patch \
+   file://0055-Fix-gfortran-build.patch \
${BACKPORTS} \
 "
 BACKPORTS = "\
diff --git a/meta/recipes-devtools/gcc/gcc-6.3/0055-Fix-gfortran-build.patch 
b/meta/recipes-devtools/gcc/gcc-6.3/0055-Fix-gfortran-build.patch
new file mode 100644
index ..30b135b9780f
--- /dev/null
+++ b/meta/recipes-devtools/gcc/gcc-6.3/0055-Fix-gfortran-build.patch
@@ -0,0 +1,53 @@
+Without this patch libbacktrace cannot be included/link during
+libgfortran build.
+
+libbtool: link: cannot find the library `../libbacktrace/libbacktrace.la'
+or unhandled argument `../libbacktrace/libbacktrace.la'
+
+Upstream-Status: Inappropriate [OE specific]
+Signed-off-by: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
+
+diff --git a/libgfortran/Makefile.am b/libgfortran/Makefile.am
+index 39d3e11d223c..b5efe6dfe195 100644
+--- a/libgfortran/Makefile.am
 b/libgfortran/Makefile.am
+@@ -37,7 +37,7 @@ toolexeclib_LTLIBRARIES = libgfortran.la
+ toolexeclib_DATA = libgfortran.spec
+ libgfortran_la_LINK = $(LINK) $(libgfortran_la_LDFLAGS)
+ libgfortran_la_LDFLAGS = -version-info `grep -v '^\#' 
$(srcdir)/libtool-version` \
+-  $(LTLDFLAGS) $(LIBQUADLIB) ../libbacktrace/libbacktrace.la \
++  $(LTLDFLAGS) $(LIBQUADLIB) ../../libbacktrace/libbacktrace.la \
+   -lm $(extra_ldflags_libgfortran) \
+   $(version_arg) -Wc,-shared-libgcc
+ libgfortran_la_DEPENDENCIES = $(version_dep) libgfortran.spec 
$(LIBQUADLIB_DEP)
+@@ -63,7 +63,7 @@ AM_CPPFLAGS = -iquote$(srcdir)/io 
-I$(srcdir)/$(MULTISRCTOP)../gcc \
+ -I$(MULTIBUILDTOP)../libgcc \
+ -I$(srcdir)/$(MULTISRCTOP)../libbacktrace \
+ -I$(MULTIBUILDTOP)../libbacktrace \
+--I../libbacktrace
++-I../../libbacktrace
+ 
+ # Fortran rules for complex multiplication and division
+ AM_CFLAGS += -fcx-fortran-rules
+diff --git a/libgfortran/Makefile.in b/libgfortran/Makefile.in
+index 7ed080cf7b0d..d197fbd6b683 100644
+--- a/libgfortran/Makefile.in
 b/libgfortran/Makefile.in
+@@ -598,7 +598,7 @@ toolexeclib_LTLIBRARIES = libgfortran.la
+ toolexeclib_DATA = libgfortran.spec
+ libgfortran_la_LINK = $(LINK) $(libgfortran_la_LDFLAGS)
+ libgfortran_la_LDFLAGS = -version-info `grep -v '^\#' 
$(srcdir)/libtool-version` \
+-  $(LTLDFLAGS) $(LIBQUADLIB) ../libbacktrace/libbacktrace.la \
++  $(LTLDFLAGS) $(LIBQUADLIB) ../../libbacktrace/libbacktrace.la \
+   -lm $(extra_ldflags_libgfortran) \
+   $(version_arg) -Wc,-shared-libgcc
+ 
+@@ -618,7 +618,7 @@ AM_CPPFLAGS = -iquote$(srcdir)/io 
-I$(srcdir)/$(MULTISRCTOP)../gcc \
+ -I$(MULTIBUILDTOP)../libgcc \
+ -I$(srcdir)/$(MULTISRCTOP)../libbacktrace \
+ -I$(MULTIBUILDTOP)../libbacktrace \
+--I../libbacktrace
++-I../../libbacktrace
+ 
+ gfor_io_src = io/size_from_kind.c $(am__append_2)
+ gfor_io_headers = \
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Re: [OE-core] [PATCH v2 1/3] gcc-6.3: Fix libgfortran build

2017-07-03 Thread Ricardo Ribalda Delgado
Hi Ross


On 3 Jul 2017 5:22 pm, "Burton, Ross" <ross.bur...@intel.com> wrote:

>
> On 30 June 2017 at 10:25, Ricardo Ribalda Delgado <
> ricardo.riba...@gmail.com> wrote:
>
>> --- a/meta/recipes-devtools/gcc/gcc-6.3.inc
>> +++ b/meta/recipes-devtools/gcc/gcc-6.3.inc
>>
>
> Is this fixed in gcc 7 (in which case the upstream-status is backport), or
> is gcc 7.1 still broken?
>

I do not know, at qtec we are following yocto, and currently it is at
version 6.3.

 I could try to build it with gcc7 during this week. and send another patch
if needed.

Regards!


>
> Ross
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH v2 3/3] libgfortran: Add missing fincludes

2017-06-30 Thread Ricardo Ribalda Delgado
ERROR: libgfortran-6.3.0-r0 do_package: QA Issue: libgfortran:
Files/directories were installed but not shipped in any package:
/usr/lib/gcc/x86_64-poky-linux/6.3.0/finclude
/usr/lib/gcc/x86_64-poky-linux/6.3.0/finclude/ieee_features.mod
/usr/lib/gcc/x86_64-poky-linux/6.3.0/finclude/ieee_arithmetic.mod
/usr/lib/gcc/x86_64-poky-linux/6.3.0/finclude/ieee_exceptions.mod

Signed-off-by: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
---
 meta/recipes-devtools/gcc/libgfortran.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/gcc/libgfortran.inc 
b/meta/recipes-devtools/gcc/libgfortran.inc
index 3b94c1b85b70..5f5d4af7589d 100644
--- a/meta/recipes-devtools/gcc/libgfortran.inc
+++ b/meta/recipes-devtools/gcc/libgfortran.inc
@@ -54,6 +54,7 @@ FILES_${PN}-dev = "\
 ${libdir}/libgfortran.la \
 ${libdir}/gcc/${TARGET_SYS}/${BINV}/libgfortranbegin.* \
 ${libdir}/gcc/${TARGET_SYS}/${BINV}/libcaf_single* \
+${libdir}/gcc/${TARGET_SYS}/${BINV}/finclude/ \
 "
 FILES_${PN}-staticdev = "${libdir}/libgfortran.a"
 
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH v2 1/3] gcc-6.3: Fix libgfortran build

2017-06-30 Thread Ricardo Ribalda Delgado
Without this patch libbacktrace cannot be included/link during
libgfortran build.

libbtool: link: cannot find the library `../libbacktrace/libbacktrace.la'
or unhandled argument `../libbacktrace/libbacktrace.la'

Signed-off-by: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
---
 meta/recipes-devtools/gcc/gcc-6.3.inc  |  1 +
 .../gcc/gcc-6.3/0099-Fix-gfortran-build.patch  | 53 ++
 2 files changed, 54 insertions(+)
 create mode 100644 
meta/recipes-devtools/gcc/gcc-6.3/0099-Fix-gfortran-build.patch

diff --git a/meta/recipes-devtools/gcc/gcc-6.3.inc 
b/meta/recipes-devtools/gcc/gcc-6.3.inc
index 86b3e9ff19a4..36a116d48fb4 100644
--- a/meta/recipes-devtools/gcc/gcc-6.3.inc
+++ b/meta/recipes-devtools/gcc/gcc-6.3.inc
@@ -74,6 +74,7 @@ SRC_URI = "\

file://0047-libgcc_s-Use-alias-for-__cpu_indicator_init-instead-.patch \
file://0048-sync-gcc-stddef.h-with-musl.patch \
file://0054_all_nopie-all-flags.patch \
+   file://0099-Fix-gfortran-build.patch \
${BACKPORTS} \
 "
 BACKPORTS = "\
diff --git a/meta/recipes-devtools/gcc/gcc-6.3/0099-Fix-gfortran-build.patch 
b/meta/recipes-devtools/gcc/gcc-6.3/0099-Fix-gfortran-build.patch
new file mode 100644
index ..30b135b9780f
--- /dev/null
+++ b/meta/recipes-devtools/gcc/gcc-6.3/0099-Fix-gfortran-build.patch
@@ -0,0 +1,53 @@
+Without this patch libbacktrace cannot be included/link during
+libgfortran build.
+
+libbtool: link: cannot find the library `../libbacktrace/libbacktrace.la'
+or unhandled argument `../libbacktrace/libbacktrace.la'
+
+Upstream-Status: Inappropriate [OE specific]
+Signed-off-by: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
+
+diff --git a/libgfortran/Makefile.am b/libgfortran/Makefile.am
+index 39d3e11d223c..b5efe6dfe195 100644
+--- a/libgfortran/Makefile.am
 b/libgfortran/Makefile.am
+@@ -37,7 +37,7 @@ toolexeclib_LTLIBRARIES = libgfortran.la
+ toolexeclib_DATA = libgfortran.spec
+ libgfortran_la_LINK = $(LINK) $(libgfortran_la_LDFLAGS)
+ libgfortran_la_LDFLAGS = -version-info `grep -v '^\#' 
$(srcdir)/libtool-version` \
+-  $(LTLDFLAGS) $(LIBQUADLIB) ../libbacktrace/libbacktrace.la \
++  $(LTLDFLAGS) $(LIBQUADLIB) ../../libbacktrace/libbacktrace.la \
+   -lm $(extra_ldflags_libgfortran) \
+   $(version_arg) -Wc,-shared-libgcc
+ libgfortran_la_DEPENDENCIES = $(version_dep) libgfortran.spec 
$(LIBQUADLIB_DEP)
+@@ -63,7 +63,7 @@ AM_CPPFLAGS = -iquote$(srcdir)/io 
-I$(srcdir)/$(MULTISRCTOP)../gcc \
+ -I$(MULTIBUILDTOP)../libgcc \
+ -I$(srcdir)/$(MULTISRCTOP)../libbacktrace \
+ -I$(MULTIBUILDTOP)../libbacktrace \
+--I../libbacktrace
++-I../../libbacktrace
+ 
+ # Fortran rules for complex multiplication and division
+ AM_CFLAGS += -fcx-fortran-rules
+diff --git a/libgfortran/Makefile.in b/libgfortran/Makefile.in
+index 7ed080cf7b0d..d197fbd6b683 100644
+--- a/libgfortran/Makefile.in
 b/libgfortran/Makefile.in
+@@ -598,7 +598,7 @@ toolexeclib_LTLIBRARIES = libgfortran.la
+ toolexeclib_DATA = libgfortran.spec
+ libgfortran_la_LINK = $(LINK) $(libgfortran_la_LDFLAGS)
+ libgfortran_la_LDFLAGS = -version-info `grep -v '^\#' 
$(srcdir)/libtool-version` \
+-  $(LTLDFLAGS) $(LIBQUADLIB) ../libbacktrace/libbacktrace.la \
++  $(LTLDFLAGS) $(LIBQUADLIB) ../../libbacktrace/libbacktrace.la \
+   -lm $(extra_ldflags_libgfortran) \
+   $(version_arg) -Wc,-shared-libgcc
+ 
+@@ -618,7 +618,7 @@ AM_CPPFLAGS = -iquote$(srcdir)/io 
-I$(srcdir)/$(MULTISRCTOP)../gcc \
+ -I$(MULTIBUILDTOP)../libgcc \
+ -I$(srcdir)/$(MULTISRCTOP)../libbacktrace \
+ -I$(MULTIBUILDTOP)../libbacktrace \
+--I../libbacktrace
++-I../../libbacktrace
+ 
+ gfor_io_src = io/size_from_kind.c $(am__append_2)
+ gfor_io_headers = \
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[OE-core] [PATCH v2 2/3] libgfortran: Add missing dependency gcc-cross

2017-06-30 Thread Ricardo Ribalda Delgado
Due to the fact that the recipe uses INHIBIT_DEFAULT_DEPS, we need to
manually add the cross compiler as a dependency.

Signed-off-by: Ricardo Ribalda Delgado <ricardo.riba...@gmail.com>
---
 meta/recipes-devtools/gcc/libgfortran.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/gcc/libgfortran.inc 
b/meta/recipes-devtools/gcc/libgfortran.inc
index 4846decbb834..3b94c1b85b70 100644
--- a/meta/recipes-devtools/gcc/libgfortran.inc
+++ b/meta/recipes-devtools/gcc/libgfortran.inc
@@ -37,7 +37,7 @@ do_install () {
 }
 
 INHIBIT_DEFAULT_DEPS = "1"
-DEPENDS = "gcc-runtime"
+DEPENDS = "gcc-runtime gcc-cross-${TARGET_ARCH}"
 
 BBCLASSEXTEND = "nativesdk"
 
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


  1   2   >