Re: [OE-core] [PATCH 00/60] krogoth-next staged

[Ian Geiser]

  On Mon, 26 Sep 2016 00:02:21 -0400 akuster808 <akuster...@gmail.com> 
wrote  
 >  
 >  
 > On 09/24/2016 07:48 AM, Ian Geiser wrote: 
 > > I think the systemd change may have broken something.  It looks like it is 
 > > running a useradd with no arguments other than the root. Now I see the 
 > > following error in krogoth: 
 > >  
 >  
 > I appears to be caused by 
 > http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=krogoth=66a4366e8fb4077a375e71c2169f3307254a36aa.
 >  
 >  
 > Master did not show this issue. 
 >  
 > - armin 
 >  
 > > from 
 > > "tmp-glibc/work/i586-oe-linux/systemd/1_229+gitAUTOINC+714c62b463-r0/temp/log.do_install"
 > >  
 > >  
 > > DEBUG: SITE files ['endian-little', 'bit-32', 'ix86-common', 
 > > 'common-linux', 'common-glibc', 'i586-linux', 'common'] 
 > > DEBUG: Executing shell function useradd_sysroot 
 > > Running groupadd commands... 
 > > NOTE: systemd: Performing groupadd with [--root 
 > > /mnt/bitbake/build/detos/tmp-glibc/sysroots/unified -r lock] 
 > > NOTE: systemd: Performing groupadd with [--root 
 > > /mnt/bitbake/build/detos/tmp-glibc/sysroots/unified  -r systemd-journal] 
 > > NOTE: systemd: group systemd-journal already exists, not re-creating it 
 > > Running useradd commands... 
 > > NOTE: systemd: Performing useradd with [--root 
 > > /mnt/bitbake/build/detos/tmp-glibc/sysroots/unified --system -d / -M 
 > > --shell /bin/nologin systemd-timesync] 
 > > NOTE: systemd: Performing useradd with [--root 
 > > /mnt/bitbake/build/detos/tmp-glibc/sysroots/unified] 

>From the looks of it the useradd is running with only the root and no actual 
>arguments.  Is it possible there is a chance in the useradd bbclass in master 
>that is needed?  Doubtful since the old code worked with the entries present.  
>What ever is happening is happening after timesync though.  I cannot see how 
>networkd is causing the problem though since it is just like the others.

 > > Usage: useradd [options] LOGIN 
 > >useradd -D 
 > >useradd -D [options] 
 > >  
 > > Options: 
 > >   -b, --base-dir BASE_DIR   base directory for the home directory of 
 > > the 
 > > new account 
 > >   -c, --comment COMMENT GECOS field of the new account 
 > >   -d, --home-dir HOME_DIR   home directory of the new account 
 > >   -D, --defaultsprint or change default useradd 
 > > configuration 
 > >   -e, --expiredate EXPIRE_DATE  expiration date of the new account 
 > >   -f, --inactive INACTIVE   password inactivity period of the new 
 > > account 
 > >   -g, --gid GROUP   name or ID of the primary group of the new 
 > > account 
 > >   -G, --groups GROUPS   list of supplementary groups of the new 
 > > account 
 > >   -h, --helpdisplay this help message and exit 
 > >   -k, --skel SKEL_DIR   use this alternative skeleton directory 
 > >   -K, --key KEY=VALUE   override /etc/login.defs defaults 
 > >   -l, --no-log-init do not add the user to the lastlog and 
 > > faillog databases 
 > >   -m, --create-home create the user's home directory 
 > >   -M, --no-create-home  do not create the user's home directory 
 > >   -N, --no-user-group   do not create a group with the same name 
 > > as 
 > > the user 
 > >   -o, --non-unique  allow to create users with duplicate 
 > > (non-unique) UID 
 > >   -p, --password PASSWORD   encrypted password of the new account 
 > >   -P, --clear-password PASSWORD clear password of the new account 
 > >   -r, --system  create a system account 
 > >   -R, --root CHROOT_DIR directory to chroot into 
 > >   -s, --shell SHELL login shell of the new account 
 > >   -u, --uid UID user ID of the new account 
 > >   -U, --user-group  create a group with the same name as the 
 > > user 
 > >  
 > > WARNING: 
 > > /mnt/bitbake/build/detos/tmp-glibc/work/i586-oe-linux/systemd/1_229+gitAUTOINC+714c62b463-r0/temp/run.useradd_sysroot.31611:1
 > >  exit 1 from 'exit 1' 
 > > ERROR: systemd: useradd command did not succeed. 
 > >  
 > >  
 > 


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

Re: [OE-core] [PATCH 00/60] krogoth-next staged

[Ian Geiser]

I think the systemd change may have broken something.  It looks like it is 
running a useradd with no arguments other than the root. Now I see the 
following error in krogoth:

from 
"tmp-glibc/work/i586-oe-linux/systemd/1_229+gitAUTOINC+714c62b463-r0/temp/log.do_install"

DEBUG: SITE files ['endian-little', 'bit-32', 'ix86-common', 'common-linux', 
'common-glibc', 'i586-linux', 'common']
DEBUG: Executing shell function useradd_sysroot
Running groupadd commands...
NOTE: systemd: Performing groupadd with [--root 
/mnt/bitbake/build/detos/tmp-glibc/sysroots/unified -r lock]
NOTE: systemd: Performing groupadd with [--root 
/mnt/bitbake/build/detos/tmp-glibc/sysroots/unified  -r systemd-journal]
NOTE: systemd: group systemd-journal already exists, not re-creating it
Running useradd commands...
NOTE: systemd: Performing useradd with [--root 
/mnt/bitbake/build/detos/tmp-glibc/sysroots/unified --system -d / -M 
--shell /bin/nologin systemd-timesync]
NOTE: systemd: Performing useradd with [--root 
/mnt/bitbake/build/detos/tmp-glibc/sysroots/unified]
Usage: useradd [options] LOGIN
   useradd -D
   useradd -D [options]

Options:
  -b, --base-dir BASE_DIR   base directory for the home directory of the
new account
  -c, --comment COMMENT GECOS field of the new account
  -d, --home-dir HOME_DIR   home directory of the new account
  -D, --defaultsprint or change default useradd configuration
  -e, --expiredate EXPIRE_DATE  expiration date of the new account
  -f, --inactive INACTIVE   password inactivity period of the new account
  -g, --gid GROUP   name or ID of the primary group of the new
account
  -G, --groups GROUPS   list of supplementary groups of the new
account
  -h, --helpdisplay this help message and exit
  -k, --skel SKEL_DIR   use this alternative skeleton directory
  -K, --key KEY=VALUE   override /etc/login.defs defaults
  -l, --no-log-init do not add the user to the lastlog and
faillog databases
  -m, --create-home create the user's home directory
  -M, --no-create-home  do not create the user's home directory
  -N, --no-user-group   do not create a group with the same name as
the user
  -o, --non-unique  allow to create users with duplicate
(non-unique) UID
  -p, --password PASSWORD   encrypted password of the new account
  -P, --clear-password PASSWORD clear password of the new account
  -r, --system  create a system account
  -R, --root CHROOT_DIR directory to chroot into
  -s, --shell SHELL login shell of the new account
  -u, --uid UID user ID of the new account
  -U, --user-group  create a group with the same name as the user

WARNING: 
/mnt/bitbake/build/detos/tmp-glibc/work/i586-oe-linux/systemd/1_229+gitAUTOINC+714c62b463-r0/temp/run.useradd_sysroot.31611:1
 exit 1 from 'exit 1'
ERROR: systemd: useradd command did not succeed.


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

Re: [OE-core] Cannot build any external kernel modules in krogoth

[Ian Geiser]

Can this get backported to krogoth?  For now i am just putting my kernel in 
RM_WORK_EXCLUDE and that seems to be working properly.  Thanks for the hint!

  On Wed, 31 Aug 2016 15:07:16 -0400 Martin Jansa <martin.ja...@gmail.com> 
wrote  
 > You're not alone, this might be the same issue (fixed only in 
 > master):https://bugzilla.yoctoproject.org/show_bug.cgi?id=9352
 > 
 > On Wed, Aug 31, 2016 at 8:38 PM, Ian Geiser <geis...@geekcentral.pub> wrote:
 > 
 >    On Tue, 30 Aug 2016 10:13:52 -0400 Ian Geiser 
 > <geis...@geekcentral.pub> wrote 
 >   > Greetings,  I have an issue where I cannot seem to build any external 
 > kernel module recipes.  The one in particular is iscsitarget, but it seems 
 > none of them build now.
 >   >
 >   > It seems that what is happening is that the 
 > "work-shared/*/kernel-build-artifacts" is getting erased right before the 
 > module recipe tries to use them.  Has anyone seen this before?
 >   >
 >   > As a key point, I am also using my own kernel recipe that only uses the 
 > kernel.bbclass, not the kernel-yocto.bbclass.  Is there magic I am missing 
 > that will not allow me to build modules unless I am using the yocto kernels?
 >   >
 >  
 >  Looking at this further it looks like this is a normal issue with all 
 > kernels.  There is a race condition that will cause the kernel to rebuild 
 > everytime you build a module.  During this process the build artifacts are 
 > always cleared out and sometimes it wont actually populate the shared 
 > workdir.  I tested with most kernels and found all modules suffer this 
 > issue.  Am I the only one seeing this?
 >  
 >  --
 >  ___
 >  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

Re: [OE-core] Cannot build any external kernel modules in krogoth

[Ian Geiser]

  On Tue, 30 Aug 2016 10:13:52 -0400 Ian Geiser <geis...@geekcentral.pub> 
wrote  
 > Greetings,  I have an issue where I cannot seem to build any external kernel 
 > module recipes.  The one in particular is iscsitarget, but it seems none of 
 > them build now. 
 >  
 > It seems that what is happening is that the 
 > "work-shared/*/kernel-build-artifacts" is getting erased right before the 
 > module recipe tries to use them.  Has anyone seen this before? 
 >  
 > As a key point, I am also using my own kernel recipe that only uses the 
 > kernel.bbclass, not the kernel-yocto.bbclass.  Is there magic I am missing 
 > that will not allow me to build modules unless I am using the yocto kernels? 
 >  
 
Looking at this further it looks like this is a normal issue with all kernels.  
There is a race condition that will cause the kernel to rebuild everytime you 
build a module.  During this process the build artifacts are always cleared out 
and sometimes it wont actually populate the shared workdir.  I tested with most 
kernels and found all modules suffer this issue.  Am I the only one seeing this?

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

[OE-core] Cannot build any external kernel modules in krogoth

[Ian Geiser]

Greetings,  I have an issue where I cannot seem to build any external kernel 
module recipes.  The one in particular is iscsitarget, but it seems none of 
them build now.

It seems that what is happening is that the 
"work-shared/*/kernel-build-artifacts" is getting erased right before the 
module recipe tries to use them.  Has anyone seen this before?

As a key point, I am also using my own kernel recipe that only uses the 
kernel.bbclass, not the kernel-yocto.bbclass.  Is there magic I am missing that 
will not allow me to build modules unless I am using the yocto kernels?

Thanks!






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

Re: [OE-core] Wic and "live" images

[Ian Geiser]

  On Wed, 25 May 2016 16:04:50 -0400 Christopher Larson 
 wrote  
 > 
 > On Wed, May 25, 2016 at 4:35 AM, Ed Bartosh  
 > wrote:
 > 
 > It's debatable. As long as we keep the logic separated, such that anything 
 > bsp specific is in the machine or bsp layer, so the images are independent 
 > of any bsp, then we're fine. If we need to keep certain aspects of rootfs / 
 > image preparation outside of wic, then we'd need the machines which need 
 > such setup to use a hook to ensure it's applied to all images, i.e. an 
 > IMAGE_POSTPROCESS_COMMAND, and we'd need to document that.

If I follow in wic the logic is in the plugins.  So its up to the bsp to 
implement those.  Currently though we have tight coupling with efi and mbr in 
the oe-core libraries.  I guess this leads me into a false sense that wic is 
machine/bsp specific.

 > That might be doable, but we definitely need to give careful thought to what 
 > pieces of information about the image creation process come from where. 
 > Certain aspects are clearly distro, i.e. extra image space, and possibly 
 > other partitioning like splitting up the rootfs into multiple partitions, 
 > but others are clearly bsp, i.e. setup of a boot partition if the bootloader 
 > expects it, and image recipes need to work regardless of what distro or 
 > machine are selected.
 
This is what I get at by saying needing a "robust" library of common plugins 
that can be reused by the bsp authors.  I think this would allow the wks files 
to be more consistent and more reusable.   

Lastly, in the current vernacular am I confusing the terms "image" and 
"rootfs"?  In my mind "image" is the physical bits that will get burned into 
ROM/SSD/etc.   "rootfs" is the filesystem component that is injected somehow 
into the image.  Is this correct?

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

Re: [OE-core] Wic and "live" images

[Ian Geiser]

  On Tue, 24 May 2016 15:56:39 -0400 Christopher Larson 
 wrote  
 > 
 > On Tue, May 24, 2016 at 12:51 PM, Ed Bartosh  
 > wrote:
 > 
 > The thing is, it's likely the machine/bsp setting the WKS_FILE, yet in 
 > OE/yocto we prefer machine/distro/image to be orthogonal. If you're 
 > injecting machine specific logic into an image, that image isn't going to be 
 > generally useful for all machines, and so violates our philosophy.

Isn't the physical disk image the place that machine/distro/image all intersect 
though?  Maybe this is some philosophy I have always not gotten because it 
seems every time I make an image for a machine I am fighting the current.  
Really I think at the core what I want is a partition layout that I can put a 
payload in.  wic seems exactly that, but I am not sure how to get from my 
rootfs, initramfs and kernel to there.  Thanks!

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

Re: [OE-core] Wic and "live" images

[Ian Geiser]

  On Tue, 24 May 2016 15:51:45 -0400 Ed Bartosh 
<ed.bart...@linux.intel.com> wrote  
 > On Mon, May 23, 2016 at 08:13:28AM -0400, Ian Geiser wrote: 
 > >  > On Thu, May 19, 2016 at 05:52:45AM -0400, Ian Geiser wrote:  

[...snip...]

 > How about creating recipe to prepare content or your boot partition and then 
 > using --source rootfs --rootfs-dir= ? 
 > This is much more generic way of creating partitioned images from my 
 > point of view. Image recipes should take care of content and wic takes care 
 > of 
 > putting that content into partitions according to the partitioning 
 > scheme described in .wks 
 >  
 > Does it make sense for you? 

I am at a loss how to do this because it is a efi system partition.  Really all 
it needs is the kernel, initramfs and bootx64.  I see how to do the kernel and 
the bootx64 in the existing plugin.  What I get turned around with is the 
initramfs.  It seems like there is no way to put that in, or use a kernel with 
the initramfs appended.  Is this a limitation that is fixed by "send a patch" 
or am I missing something there.

 >  
 > >  
 > >  > You can probably do the same by using wic plugins, but I'd not suggest  
 > >  > to go this way. Using wic image type is simpler, more consistent, 
 > > easier to do and provides higher level of automation.  
 > >  
 > > Is using the wic image type and a plugin mutually exclusive? 
 > No, not at all. However, I personally found the way I described above 
 > more consistent, flexible and easy to implement and maintain. 
 
I am not groking this concept because it seems without a robust library of 
plugins the wks files become very hard to implement.  Is this true, or am I 
again missing something obvious.

Thanks for your patience. 

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

Re: [OE-core] Wic and "live" images

[Ian Geiser]

  On Mon, 23 May 2016 09:00:28 -0400 Sergey Jin Bostandzhyan 
<j...@mediatomb.cc> wrote  
 > Hi, 
 >  
 > I'm risking to land in the "reinvented the wheel" corner, but basically I 
 > had a task to create images with msdos partitions, while at the same time 
 > some things had to be in areas where parted/fdisk were not able to create a 
 > partition yet (i.e. u-boot had to be at a very early offset in the image). 
 >  
 > wic seemed too PC oriented and cumbersome to me, so I came up with 
 > a custom class: 
 >  
 > https://git.digitalstrom.org/dss-oe/dss-oe/blob/master/yocto/dS/meta-digitalstrom-devel/classes/msdos_partition_image.bbclass
 >  
 >  
This is more or less what I have now.  I was trying to move to 'wic' because 
the 'image-vm.bbclass' cannot handle some of the things I want.  From the 
manual it sounds like wic is more flexible, but I think it is only flexible in 
the way you can use plugins to create new partition types.  It also lacks any 
sort of dependency tracking with bitbake so you cannot use it from there 
without a lot of manual hand holding.  I think for the limited types it 
currently handles it is less capable than image-vm.bbclass.

 > I have a multimachine configuration which then looks like this (example with 
 > raw image outside a partition): 
 > https://git.digitalstrom.org/dss-oe/dss-oe/blob/master/yocto/dS/meta-digitalstrom-devel/recipes-core/images/dss20-image.inc
 >  
 >  
 > Or this (example with extended partition): 
 > https://git.digitalstrom.org/dss-oe/dss-oe/blob/master/yocto/dS/meta-digitalstrom-devel/recipes-core/images/dss11e-image.inc
 >  
 >  
 > The DSSIMG_TASK_DEPENDS variable lists all things that will be 
 > written into the final image (i.e. u-boot, rescue fs, root fs). 
 >  
 > If someone considers this interesting for OE in general, I can surely tune 
 > a few things and submit a patch for review. 
 
I do find this very interesting.  From the looks of it there seems to be more 
extensibility than can be had with image-vm.bbclass or wic.

>  
 > Kind regards, 
 > Jin 
 >  
 >  
 >  
 > On Mon, May 23, 2016 at 08:13:28AM -0400, Ian Geiser wrote: 
 > >   On Mon, 23 May 2016 06:36:23 -0400 Ed Bartosh 
 > > <ed.bart...@linux.intel.com> wrote   
 > >  > On Thu, May 19, 2016 at 05:52:45AM -0400, Ian Geiser wrote:  
 > >  > > Greetings, I am trying to learn "wic" and have been confused as how 
 > > to create a "live" style image.  I am following 
 > > "http://www.yoctoproject.org/docs/1.5.2/dev-manual/dev-manual.html#creating-partitioned-images;
 > >  but am getting confused on the target to use to create the a file system 
 > > that has a single squashfs file containing my root file system.
 > >  > >   
 > >  > > My desired partition layout is as follows:  
 > >  > >   40MiB 40MiB   300MiB  
 > >  > > 
 > > ++-+-+  
 > >  > > |  BOOT (esp)|DATA (fat)   |  ROOT (live)
 > > |
 > >  > > 
 > > ++-+-+  
 > >  > >   
 > >  > > BOOT - efi boot partition with kernel and initramfs  
 > >  > > DATA - generic fat filesystem to hold configuration files  
 > >  > > ROOT - an ext4 filesystem that contains a single os.img, which is a 
 > > squashfs file.  
 > >  > >   
 > >  > > I have ROOT and DATA figured out but I am at a loss as how to 
 > > generate the os.img file and copy it into ROOT.  If I generate the os.img 
 > > file with bitbake and then use the "-r" option to manually supply a 
 > > directory structure it works, but I would rather have it done from a wks 
 > > file for automation reasons.  
 > >  > >   
 > >  > > Any hints?  
 > >  > I'd suggest to use wic image type and generate your image by bitbake.  
 > >  > You can find example wic-image-minimal.bb and wic-image-minimal.wks in 
 > > ../meta-selftest/recipes-test/images/  
 > >  >   
 > > This is where I started.  I was able to make it work but not with my 
 > > configuration above.  It looks like I can use a type of "fsimage" for my 
 > > "ROOT" partition, but I have not been able to figure out the syntax there 
 > > yet.  For "BOOT" I am at a complete loss.  In theory "bootimg-efi" but 
 > > there doesn't seem to be a way to provide an initramfs. 
 > >  
 > >  > You can probably do the same by using wic plugins, but I'd not suggest  
 > >  > to g

Re: [OE-core] Wic and "live" images

[Ian Geiser]

  On Mon, 23 May 2016 06:36:23 -0400 Ed Bartosh 
<ed.bart...@linux.intel.com> wrote  
 > On Thu, May 19, 2016 at 05:52:45AM -0400, Ian Geiser wrote: 
 > > Greetings, I am trying to learn "wic" and have been confused as how to 
 > > create a "live" style image.  I am following 
 > > "http://www.yoctoproject.org/docs/1.5.2/dev-manual/dev-manual.html#creating-partitioned-images;
 > >  but am getting confused on the target to use to create the a file system 
 > > that has a single squashfs file containing my root file system.   
 > >  
 > > My desired partition layout is as follows: 
 > >   40MiB 40MiB   300MiB 
 > > ++-+-+ 
 > > |  BOOT (esp)|DATA (fat)   |  ROOT (live)|   
 > > ++-+-+ 
 > >  
 > > BOOT - efi boot partition with kernel and initramfs 
 > > DATA - generic fat filesystem to hold configuration files 
 > > ROOT - an ext4 filesystem that contains a single os.img, which is a 
 > > squashfs file. 
 > >  
 > > I have ROOT and DATA figured out but I am at a loss as how to generate the 
 > > os.img file and copy it into ROOT.  If I generate the os.img file with 
 > > bitbake and then use the "-r" option to manually supply a directory 
 > > structure it works, but I would rather have it done from a wks file for 
 > > automation reasons. 
 > >  
 > > Any hints? 
 > I'd suggest to use wic image type and generate your image by bitbake. 
 > You can find example wic-image-minimal.bb and wic-image-minimal.wks in 
 > ../meta-selftest/recipes-test/images/ 
 >  
This is where I started.  I was able to make it work but not with my 
configuration above.  It looks like I can use a type of "fsimage" for my "ROOT" 
partition, but I have not been able to figure out the syntax there yet.  For 
"BOOT" I am at a complete loss.  In theory "bootimg-efi" but there doesn't seem 
to be a way to provide an initramfs.

 > You can probably do the same by using wic plugins, but I'd not suggest 
 > to go this way. Using wic image type is simpler, more consistent, easier to 
 > do and provides higher level of automation. 

Is using the wic image type and a plugin mutually exclusive?

Thanks!



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

[OE-core] Wic and "live" images

[Ian Geiser]

Greetings, I am trying to learn "wic" and have been confused as how to create a 
"live" style image.  I am following 
"http://www.yoctoproject.org/docs/1.5.2/dev-manual/dev-manual.html#creating-partitioned-images;
 but am getting confused on the target to use to create the a file system that 
has a single squashfs file containing my root file system.  

My desired partition layout is as follows:
  40MiB 40MiB   300MiB
++-+-+
|  BOOT (esp)|DATA (fat)   |  ROOT (live)|  
++-+-+

BOOT - efi boot partition with kernel and initramfs
DATA - generic fat filesystem to hold configuration files
ROOT - an ext4 filesystem that contains a single os.img, which is a squashfs 
file.

I have ROOT and DATA figured out but I am at a loss as how to generate the 
os.img file and copy it into ROOT.  If I generate the os.img file with bitbake 
and then use the "-r" option to manually supply a directory structure it works, 
but I would rather have it done from a wks file for automation reasons.

Any hints?

Thanks!



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

Re: [OE-core] [PATCH v2] Allow different filesystems to be used for VM images.

[Ian Geiser]

What is the status of this patch?

  On Fri, 29 Apr 2016 08:41:49 -0400 Ian Reinhart Geiser 
 wrote  
 > This allows for things like btrfs to be used vs just ext4. 
 > The default value of ext4 is kept so there is no functional 
 > change unless VM_ROOTFS_TYPE is set in the inherting recipe. 
 >  
 > Signed-off-by: Ian Reinhart Geiser  
 > --- 
 >  meta/classes/image-vm.bbclass | 13 +++-- 
 >  1 file changed, 7 insertions(+), 6 deletions(-) 
 >  
 > diff --git a/meta/classes/image-vm.bbclass b/meta/classes/image-vm.bbclass 
 > index 47f7326..2bbd9d3 100644 
 > --- a/meta/classes/image-vm.bbclass 
 > +++ b/meta/classes/image-vm.bbclass 
 > @@ -23,16 +23,17 @@ do_bootdirectdisk[depends] += 
 > "dosfstools-native:do_populate_sysroot \ 
 > syslinux-native:do_populate_sysroot \ 
 > parted-native:do_populate_sysroot \ 
 > mtools-native:do_populate_sysroot \ 
 > -   ${PN}:do_image_ext4 \ 
 > +   ${PN}:do_image_${VM_ROOTFS_TYPE} \ 
 > " 
 >   
 > -IMAGE_TYPEDEP_vmdk = "ext4" 
 > -IMAGE_TYPEDEP_vdi = "ext4" 
 > -IMAGE_TYPEDEP_qcow2 = "ext4" 
 > -IMAGE_TYPEDEP_hdddirect = "ext4" 
 > +IMAGE_TYPEDEP_vmdk = "${VM_ROOTFS_TYPE}" 
 > +IMAGE_TYPEDEP_vdi = "${VM_ROOTFS_TYPE}" 
 > +IMAGE_TYPEDEP_qcow2 = "${VM_ROOTFS_TYPE}" 
 > +IMAGE_TYPEDEP_hdddirect = "${VM_ROOTFS_TYPE}" 
 >  IMAGE_TYPES_MASKED += "vmdk vdi qcow2 hdddirect" 
 >   
 > -ROOTFS ?= "${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.ext4" 
 > +VM_ROOTFS_TYPE ?= "ext4" 
 > +ROOTFS ?= "${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.${VM_ROOTFS_TYPE}" 
 >   
 >  # Used by bootloader 
 >  LABELS_VM ?= "boot" 
 > --  
 > 2.8.1 
 >  
 > 

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

Re: [OE-core] [PATCH] Allow different filesystems to be used for VM images.

[Ian Geiser]

  On Fri, 29 Apr 2016 04:19:00 -0400 Richard Purdie 
 wrote  
 > On Thu, 2016-04-28 at 15:21 -0400, Ian Reinhart Geiser wrote: 
 > > This allows for things like btrfs to be used vs just ext4. 
 > > The default value of ext4 is kept so there is no functional 
 > > change unless ROOTFS_TYPE is set in the inherting recipe. 
 > >  
 > > Signed-off-by: Ian Reinhart Geiser  
 > > --- 
 > >  meta/classes/image-vm.bbclass | 13 +++-- 
 > >  1 file changed, 7 insertions(+), 6 deletions(-) 
 >  
 >  
 > This seems reasonable but could I ask you to use a variable name with 
 > "VM" in the name please? 
 >  
 > I appreciate some of the existing ones don't do this but moving forward 
 > we need to try and better namespace some of these class specific 
 > variables and this seems like a good place to start. 
 >  
 > VM_ROOTFS_TYPE would be better for example (or VMIMG_ROOTFS_TYPE). 
 >  
The other ones have foo_VM in the name.  Would ROOTFS_TYPE_VM be acceptable?

 > Cheers, 
 >  
 > Richard 
 >  
 > > diff --git a/meta/classes/image-vm.bbclass b/meta/classes/image 
 > > -vm.bbclass 
 > > index 47f7326..50d93d5 100644 
 > > --- a/meta/classes/image-vm.bbclass 
 > > +++ b/meta/classes/image-vm.bbclass 
 > > @@ -23,16 +23,17 @@ do_bootdirectdisk[depends] += "dosfstools 
 > > -native:do_populate_sysroot \ 
 > > syslinux-native:do_populate_sysroot \ 
 > > parted-native:do_populate_sysroot \ 
 > > mtools-native:do_populate_sysroot \ 
 > > -   ${PN}:do_image_ext4 \ 
 > > +   ${PN}:do_image_${ROOTFS_TYPE} \ 
 > > " 
 > >   
 > > -IMAGE_TYPEDEP_vmdk = "ext4" 
 > > -IMAGE_TYPEDEP_vdi = "ext4" 
 > > -IMAGE_TYPEDEP_qcow2 = "ext4" 
 > > -IMAGE_TYPEDEP_hdddirect = "ext4" 
 > > +IMAGE_TYPEDEP_vmdk = "${ROOTFS_TYPE}" 
 > > +IMAGE_TYPEDEP_vdi = "${ROOTFS_TYPE}" 
 > > +IMAGE_TYPEDEP_qcow2 = "${ROOTFS_TYPE}" 
 > > +IMAGE_TYPEDEP_hdddirect = "${ROOTFS_TYPE}" 
 > >  IMAGE_TYPES_MASKED += "vmdk vdi qcow2 hdddirect" 
 > >   
 > > -ROOTFS ?= "${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.ext4" 
 > > +ROOTFS_TYPE ?= "ext4" 
 > > +ROOTFS ?= "${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.${ROOTFS_TYPE}" 
 > >   
 > >  # Used by bootloader 
 > >  LABELS_VM ?= "boot" 
 > > --  
 > > 2.8.0.rc3 
 > >  
 > >  
 > 

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

Re: [OE-core] debugedit: canonicalization unexpectedly shrank by one character

[Ian Geiser]

 -Original Message-
 From: openembedded-core-boun...@lists.openembedded.org
 [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
 Martin Jansa
 Sent: Wednesday, April 24, 2013 3:20 AM
 To: openembedded-core@lists.openembedded.org
 Subject: [OE-core] debugedit: canonicalization unexpectedly shrank by
 one character
 
 Hi,
 
 with debugedit errors now catched and shown after:
 commit 262a69ffd33e9d001a7a15fc73671a015e3b5dd1
 Author: Richard Purdie richard.pur...@linuxfoundation.org
 Date:   Mon Mar 25 16:52:07 2013 +
 
 package.bbclass: Handle subprocess errors correctly
 
 If an error occurs in subprocess.call() we currently don't catch
 it. In particular
 we have issues where debugedit is segfaulting unnoticed. This fixes
 up
 various code paths to catch the errors.
 
 I get couple of recipes failing with errors like:
[...]
 This leads to
 https://bugzilla.redhat.com/show_bug.cgi?id=304121
 https://bugs.launchpad.net/rpm/+bug/638633
 https://qa.mandriva.com/show_bug.cgi?id=62391
 
 but no clear solution (it would be nice to show which path triggered
 that message as suggested in redhat bugzilla)
 
 I can INHIBIT_PACKAGE_DEBUG_SPLIT in failing recipes or adding slash to
 -d '/usr/src/debug/' works in this case too..
I tried set PACKAGE_DEBUG_SPLIT_STYLE = debug-without-src in the package and 
that seemed to work around the problem.  In my package that was offending was 
because there was an -rpath that had a trailing /.  It seems debugedit is very 
sensitive to rogue path separators. Are there ways to make this more robust?



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

[OE-core] state of systemd in oe

[Ian Geiser]

Hey, I noticed that systemd service files are going back into the oe-core layer 
and not always compatible with meta-oe.  What is the official policy on systemd 
right now?  Is it supposed to be confined to the meta-oe/meta-systemd layer?  
Or what cases will they be pulled in and/or duplicated in oe-core?  Thanks!


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

[OE-core] OpenGL as a DISTRO_FEATURE

[Ian Geiser]

Greetings, I maintain 3 different platforms with varying degrees of GL support. 
 Would it make more sense to migrate the opengl distro feature to 
MACHINE_FEATURES?  This way we could compensate for the platforms that use Mesa 
and the ones that use their custom implementations?  Thoughts?


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

Re: [OE-core] OpenGL as a DISTRO_FEATURE

[Ian Geiser]

 -Original Message-
 From: Ross Burton [mailto:ross.bur...@intel.com]
 Sent: Sunday, February 03, 2013 2:04 PM
 To: Ian Geiser
 Cc: openembedded-core@lists.openembedded.org
 Subject: Re: [OE-core] OpenGL as a DISTRO_FEATURE
 
 On Sunday, 3 February 2013 at 17:15, Ian Geiser wrote:
  Greetings, I maintain 3 different platforms with varying degrees of
 GL support. Would it make more sense to migrate the opengl distro
 feature to MACHINE_FEATURES? This way we could compensate for the
 platforms that use Mesa and the ones that use their custom
 implementations? Thoughts?
 
 Even if there were machine features, a distro feature is still
 something you'd want.
 
 There's been the idea of having fine-grained machine features for the
 aspects of OpenGL that the hardware supports (gl, gles, egl, etc).
 It's not as simple as it appears and causes a rather large number of
 packages to become machine-specific.
In the case of my product that is not a problem.  It may have implications on 
the community distributions though.

 
 What would you use the machine features for?  Conditionally compiling
 support for a particular variant of GL into packages that cannot be
 detected at runtime, or something else?
 
The case I have is 3 platforms:
1) Atom N450
2) WM 8950
3) VIA VX900

The Atom has the normal mesa-dri drivers and can use the OpenGL implementation 
from that.  The WM has only OpenGLES drivers and no OpenGL implementation.  So 
in that case I want to use only GLES support in the various packages that 
conditionally support it (in my case Qt4).  The last platform the VIA has its 
own OpenGL implementation that can completely replace mesa for packages that 
support OpenGL. In the case of my distro I support Qt4 but it can use OpenGLES 
or OpenGL.  The problem comes in when I start setting preferred providers in 
the machine conf files.  In the case of my WM, I have only gles and since the 
distro supports opengl, it needs a virtual/libgl and finds it with mesa.  Now I 
can remove opengl from my distro, but the Atom and VIA support opengl, and will 
not have it available to Qt because it turns off.  

So really on reflection the real problem is that when you support two platforms 
in the same distro that either have opengl or opengles you get into trouble.  
Now one approach might be to make a distro based off of the common distro that 
supports either opengl or opengles but that to me sounds like I am fixing the 
problem in the wrong place.
 
Now I could be missing an obvious better way.


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

Re: [OE-core] OpenGL as a DISTRO_FEATURE

[Ian Geiser]

 -Original Message-
 From: openembedded-core-boun...@lists.openembedded.org
 [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
 Marcin Juszkiewicz
 Sent: Sunday, February 03, 2013 4:34 PM
 To: openembedded-core@lists.openembedded.org
 Subject: Re: [OE-core] OpenGL as a DISTRO_FEATURE
 
 W dniu 03.02.2013 20:45, Ian Geiser pisze:
 
  The case I have is 3 platforms: 1) Atom N450 2) WM 8950 3) VIA VX900
 
  The Atom has the normal mesa-dri drivers and can use the OpenGL
  implementation from that.  The WM has only OpenGLES drivers and no
  OpenGL implementation.  So in that case I want to use only GLES
  support in the various packages that conditionally support it (in my
  case Qt4).  The last platform the VIA has its own OpenGL
  implementation that can completely replace mesa for packages that
  support OpenGL. In the case of my distro I support Qt4 but it can use
  OpenGLES or OpenGL.  The problem comes in when I start setting
  preferred providers in the machine conf files.  In the case of my WM,
  I have only gles and since the distro supports opengl, it needs a
  virtual/libgl and finds it with mesa.  Now I can remove opengl from
  my distro, but the Atom and VIA support opengl, and will not have it
  available to Qt because it turns off.
 
 As they are different architectures you can try this:
 
 DISTRO_FEATURES_wm8950 = here copy your default DISTRO_FEATURES but
 skip opengl
 
 Replace wm8950 with MACHINE name. Ugly solution but should work.
Then I have 3 DISTRO_FEATURES lines in my distro.conf, or I have 
DISTRO_FEATURES spread out inside of my machine.conf files.  Ugly solutions 
ship, but elegant solutions get maintained ;)



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

Re: [OE-core] OpenGL as a DISTRO_FEATURE

[Ian Geiser]

 -Original Message-
 From: openembedded-core-boun...@lists.openembedded.org
 [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
 Ross Burton
 Sent: Sunday, February 03, 2013 6:35 PM
 To: Marcin Juszkiewicz
 Cc: openembedded-core@lists.openembedded.org
 Subject: Re: [OE-core] OpenGL as a DISTRO_FEATURE
 
 On Sunday, 3 February 2013 at 21:33, Marcin Juszkiewicz wrote:
  As they are different architectures you can try this:
 
  DISTRO_FEATURES_wm8950 = here copy your default DISTRO_FEATURES but
  skip opengl
 
  Replace wm8950 with MACHINE name. Ugly solution but should work.
 That means that Qt won't be built with GLES support.
 
 The best approach is to probe the hardware/libraries at runtime and
 adapt - i.e. if only GLES libraries are available use those, but a lot
 of software doesn't support that or simple probing isn't sufficient
 (Intel Pine Trail supports both but GL is best, Cedar Trail supports
 both but GL is terrible).
In my instance I know what hardware I am targeting at build time so I can make 
the choice there.  That is why I think MACHINE_FEATURES might be more 
appropriate.

That being said a grep through a few layers shows that this might not be a low 
impact change so Marcin's solution while not ideal might be the least amount 
the churn.



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

Re: [OE-core] [PATCH 17/17] directfb: Explictly disable mesa

[Ian Geiser]

 -Original Message-
 From: openembedded-core-boun...@lists.openembedded.org
 [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
 Richard Purdie
 Sent: Wednesday, January 30, 2013 9:01 AM
 To: openembedded-core@lists.openembedded.org
 Subject: [OE-core] [PATCH 17/17] directfb: Explictly disable mesa
 
 Without this, directfb might build with mesa enabled if present.
 
Is it possible to make this tunable?  We use directfb with the mesa dri drivers 
for opengl.  Maybe enable it only if the distro features contains opengl?

Thanks!


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

Re: [OE-core] [PATCH 17/17] directfb: Explictly disable mesa

[Ian Geiser]

 -Original Message-
 From: Burton, Ross [mailto:ross.bur...@intel.com]
 Sent: Wednesday, January 30, 2013 9:53 AM
 To: Ian Geiser
 Cc: openembedded-core@lists.openembedded.org
 Subject: Re: [OE-core] [PATCH 17/17] directfb: Explictly disable mesa
 
 On 30 January 2013 14:43, Ian Geiser igei...@devonit.com wrote:
  Without this, directfb might build with mesa enabled if present.
 
  Is it possible to make this tunable?  We use directfb with the mesa
 dri drivers for opengl.  Maybe enable it only if the distro features
 contains opengl?
 
 I was just saying to Richard that if someone wants it, we can enable
 it.
 
 Basing on the opengl distro feature makes some sense, as long as
 people are aware of the interaction between directfb and opengl,
 especially on platforms where Mesa may not be the GL implementation.
 
 An alternative would be to make it a non-default PACKAGECONFIG option,
 so you can enable it because you know that you have Mesa as your GL
 provider.

Now that you suggest it I like the PACKAGECONFIG option because its trivial to 
work with from the distro without impacting other things.  It also streamlines 
the dependencies and configure options.  Thanks!

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

Re: [OE-core] [PATCH] mesa-dri: add extra dri drivers

[Ian Geiser]

 -Original Message-
 From: Burton, Ross [mailto:ross.bur...@intel.com]
 Sent: Wednesday, January 30, 2013 10:16 AM
 To: Ian Geiser
 Cc: openembedded-core@lists.openembedded.org
 Subject: Re: [OE-core] [PATCH] mesa-dri: add extra dri drivers
 
 On 30 January 2013 13:26,  igei...@devonit.com wrote:
  On x86 the ATI and NVidia drm drivers are valid to build.
  Currently there are _append_x86 and _append_x64 lines that explicitly
  add i915 and i965.  For consistency I think that the ATI and NVidia
  drm driver should be added. In classic these were tunable via the
  machine configuration files. I would argue we should go back to that
  so we should make the DRIDRIVERS field something that can be defined
  there.
 
  * Made the DRIDRIVERS field overridable.
  * Add ATI and NVidia DRI drivers to the build list for
x86 and x86_64.
 
 I'm not sure why we need to make this machine-tunable - we currently
 build all drivers in libdrm (but split them between packages), so why
 not just enable all working DRI drivers in Mesa and split them between
 packages.
 
 Machine configurations can pull in specific driver packages (or all of
 them) without making Mesa itself machine-specific.
 
 Can you send a V2 without the conditional assignment (unless you have
 an argument for keeping it), with a commit message that just describes
 the patch.
No, I was just extending what was there so I have no real preference.  I will 
need to check if it impacts non-x86 builds.  I do not think it will be a 
problem, since most non-x86 systems have their own GL implementations.  I think 
it will just enable swrast on ones that are not x86.  I will resubmit with it 
set to auto where it will only build the appropriate drivers after I test.  
Thanks!

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