Re: [yocto] sysroot for use with GDB

[Mark Hatle]

On 12/5/12 6:38 AM, Wolfgang Denk wrote:

Hello,

nobody here who could help out?

In message <20121203124234.6327b200...@gemini.denx.de> I wrote:


according to the documentation [1] the right way to debug applications
on the target is to load the target library information in GDB using

set solib-absolute-prefix /path/to/tmp/rootfs

i. e. referring it to the libraries in the target root file system
image.  Assuming the target root file system uses by defualt stripped
libraries, we need to set up a copy of the rootfs with debug
information included.

But do we really have to?  Why cannot we use the libraries present in
the SDK's sysroot directory (i. e. what OECORE_TARGET_SYSROOT points
to) ?


It appears that documentation and code are inconsistent; at least the
eclipse plugin generates a .gdbinit script which contains a

set sysroot /opt/poky/1.3/sysroots/armv7a-vfp-neon-poky-linux-gnueabi

statement, i. e. it uses OECORE_TARGET_SYSROOT as I thought should
work - but it doesn't.


Trying to do so, we see that it fails.  Our current suspicion is that
maybe prelinking of the target images and libraries introduces some
incompatibility.  Is this a reasonable assumption, and if so, is this
a problem that should be fixed, or unavoidable for some reason?  Or is
there a problem with the libraries in OECORE_TARGET_SYSROOT ?


Prelinking should not cause a problem.  GDB knows how to translate the debuginfo 
addresses to the end runtime addresses.


The only thing I've seen in the past that has caused a problem is when the dbg 
stuff was not installed into the sysroot.  GDB will fall back into loading the 
binaries from the sysroot, which will not contain the debug info causing problems.


It's best if you can set the sysroot to the same filesystem as being executed, 
but if you can't this is reasonable.



All help welcome - thanks in advance.

[1] 
http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#platdev-gdb-remotedebug-launch-gdb


OK, guess I should enter a bug in bugzilla, then?





Best regards,

Wolfgang Denk



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

Re: [yocto] Need for offline binary configuration

[Mark Hatle]

My apologies for the late response.  See below, I'll follow up on your second 
email as well...


On 11/20/12 9:09 AM, Venkata ramana gollamudi wrote:

Poky allows to build custom Linux for you, but we have cases where the post
build customization is required, like user-addition, network configuration,
service control. Even selecting the required packages can be a post build 
activity.


One of the objectives that we are currently working toward is being able to 
start with the package feed (doesn't matter if it's rpm, deb or ipk files), 
generate a rootfs, configure the rootfs and then deploy the rootfs into an image.


The above should be able to be done on both a cross-configured environment or on 
the target via a traditional installer like mechanism.



The current model requires the image to be rebuilt to support these 
configuration.


The current model can avoid many of the tasks associated with the build by using 
sstate-cache, but I agree that is not optimal for users who want to start with a 
known set of binaries and then tailor from that point.  (This includes users 
expecting a more traditional Linux install experience or users who need 
immutable software from an upstream vendor.)



Offline Configuration tool (OCT), which allows a binary image customization
before making a final target image. This case will be more evident in larger
companies, where platform teams, product teams , application teams are
distributed and Linux build from source will be owned and lab tested by a single
team, like platform team. Other teams just configure to use it for product
variants from same platform build.


This was factored into the work we are doing.  I know many companies have an 
outside OSV that provides the build environment, support, etc.. and they feed 
into an Operating Systems group (or similar).  This group then prepares the 
software according to the corporate guidelines (license restrictions, quality 
assurance, etc) and repackages it for consumption by others in the organization. 
 Often time the output of the Operating System group is either a blessed source 
based system -- or a set of binaries that are blessed as being in conformance 
with that companies guidelines.  This process repeats through the platform group 
and even individual projects -- with the eventual output being a product image 
including the blessed binaries, custom applications and configurations -- and a 
matching SDK.



Detailed use cases can be found in enhancement bug:3252

OCT should work on the binary pool of compiled packages generated from poky.

The basic operations that can be supported includes


For the next section, I'm going to assume the pool of binary packages is what we 
refer to as the package feeds in OpenEmbedded.  This is simple a collection of 
binary packages that have been built from the build system that can be used to 
construct the rootfs.  Each package feed is constructed based on a single 
"distribution" configuration file which sets the policies for the packages in 
the feed and distribution wide options, such as selinux, pam, etc.



a) Select/deselect required packages from pool of binary packages into final 
target image.


The above is definitely considered in the work we've been talking about.  This 
will require software that will take a list of the available items in the feed, 
present the user/developer with a way to enable the components they want on the 
target.  (Note, there is an inherit requirement here that dependencies also be 
met, so things the user/developer may not have selected will either have to be 
installed to meet dependencies or will have to generate an error that 
dependencies can't be met.)



b) Provision to select external binary packages like ADT compiled applications 
as input and add them to final target image.


As long as the external package is in the same format as the rest of the feeds, 
this should be easy to do.  And I certainly expect that it will be needed.



c) Binary level Offline configuration can includes
   Configure the users/passwords
   Configure the network
   Configure the host name
   Select the services to be started by default


The above are things we've talked about, but I don't believe there have been any 
formal plans to implement them at this time.  The components necessary for the 
binary package based install -> rootfs generation have taken up most of our 
planning time at this point.


One thing I would love to see is a set of standard components (or a framework) 
that could be used for this type of configuration.  But I believe it's very 
important that the configuration work both within the OpenEmbedded environment 
and externally in the "installer" like environment.



   Security related configuration


This is something that I don't believe has really been addressed at all, but 
like the above we need a way to implement it.



   Generate initrd in ramfs/ext3/... format
   etc..


We are already c

Re: [yocto] Need for offline binary configuration

[Mark Hatle]

On 11/29/12 5:09 AM, Venkata ramana gollamudi wrote:

Added few more thoughts
Looking for possible options to implement Offline Configuration Tool 
requirement. please check and comment on it.

Configuration flow:

a) Task do_createconfig will generate data to configure. This serves as input 
for configuration UI in OCT.


Using tasks to control the configuration elements will require the build system 
and recipes.  This is really good for the existing workflow, but doesn't help 
with the blessed binaries situation.


What I'd love to see (but don't expect) is a way for the binary packages to 
document he configuration files and options in a way that the UI can load this 
information, give the user simple check-box/drop down style configuration -- or 
simply a text editor with the end result something that gets back to the target 
environment.



b) OCT UI will read that config data(from step(a)) to show it in GUI. User 
configures using GUI inputs. Stores the user OCT configuration to OCT config 
file. (Note user can directly modify the OCT config file, if User is familier 
with it)

c) preinst, postinst, prerm, postrm, or a do_applyconfig(without bb files 
reparse), can read OCT config file content (using a library) and apply 
necessary changes.


I'm not sure pre/post is the right place to do these changes.  Typically I've 
seen the default configuration files marked as such within the package system 
and then the modifications are made externally.  Sometimes they're made in 
ancillary packages or just made raw on the disk.  Most package management 
systems I'm aware of can handle this just fine.


My concern with modifying the defaults is that the feed become project specific, 
and again it requires input during the build process as opposed to the install 
process.



Now we can look into possibility of using a specific configuration UI 
implementation or a generic configuration model or combination of both.

1) Using a specific configuration GUI implementation:
do_createconfig generates the configuration information, in format like 
datafile/xml and OCT reads this config data and provides a GUI to modify or 
configure the features.

Pros: Detailed and complex GUIs can be supported which will be user friendly. 
Ex: User management, network management etc.
Cons: As UI is static, it has to be modified to support new configuration 
requirements
and UI modifications are generally complex.


Having something like a do_createconfig (or even a do_describeconfig) to 
generate a file that is later made available to the UI tool is my suggestion. 
Then the input/output of the tool ends up in the rootfs directly.  (The methods 
to get to the rootfs should be either a specific path, a URL for get/put 
operations, or a method like tcf/ssh to copy the item to a running target.


Either a custom per-package model or a generic model may be needed.  I don't 
know what the best approach is -- however I know previous attempts to do this 
have generally resulted in more 'custom' model then generic + config file model.


But in general there seem to be three main types of configuration files that 
I've seen:


Column/format based -- i.e. /etc/fstab, /etc/exports
Key/Value based -- things like Key=Value, or Key:\nValue, etc..
XML-like -- Highly formatted configuration files like apache.

--Mark


2) A generic configuration model
do_createconfig generates configuration information with presentation 
information included (like kconfig) and OCT reads this config information and 
provides a generic UI implementation to modify or config the data like 
menuconfig.

Pros:
- Generic and dynamic UI allowing the config menus to be added from 
poky layers providing platform for configuration.
- New features can add new menus configuration options. Feature/package 
enable and disable can control the configurtion menus.
- So configuration is shown only if feature/package is present/selected.
Cons:
- Generic method of implementing can be complex, specifically for 
features where configuration is complex ex: User management, network 
configuration.
- Custom or specific UI will be more user friendly and gives more 
control to UI designer.

3) Combination of both
Complex features requiring more UI control can implement those features using 
the method(1) and also providing the plaform for generic UI implementation.
OCT displays both UI configurations.
Ex: Static Image level features like User management, network config can be 
implemented using method(1)
 Service configuration, file system type, hist size configure etc can be 
implemented using method(2).

Pros: Gives control to project to select the Complex and simple UIs.

Cons: Still needs a OCT UI change if method(1) feature need to be changed.
   Drawing a line between complex and simple UI features may not very 
straight forward.
   Adding dynamic Complex UI is not possible to be added from poky layers.

Decision to provide a

Re: [yocto] Difference of toolchain recipes

[Mark Hatle]

On 12/6/12 4:00 AM, Luo Zhenhua-B19537 wrote:

Can anybody shed some light, please?


Best Regards,

Zhenhua



-Original Message-
From: Luo Zhenhua-B19537
Sent: Tuesday, December 04, 2012 11:53 AM
To: openembedded-c...@lists.openembedded.org; 'yocto@yoctoproject.org'
Subject: Difference of toolchain recipes

It is a bit confused for the different recipes of toolchian, can somebody
help to explain what's the difference for those recipes? E.g. gcc-cross,
gcc-cross-canadian, gcc-cross-initial, gcc-cross-intermediate, gcc-
crosssdk, gcc-crosssdk-initial, gcc-crosssdk-intermediate, gcc-runtime,
etc.


gcc-cross-initial - This is the initial compiler needed to bootstrap the 
toolchain to build software on the host for the target.  (This is a 'native' 
package.)


gcc-cross-intermediate - This is the second stage of the bootstrap process to 
build software on the host for the target. (This is a 'native' package.)


gcc-cross - this is the the final stage of the bootstrap process, and results in 
the cross compiler to build software on the host for the target.  (This is a 
'native' package.)  If you are replacing the cross compiler toolchain with a 
custom version, this is what you must replace.


gcc-runtime - these are the runtime libraries, but from the toolchain 
bootstrapping process.  This results in a 'target' binary.


gcc-crosssdk-initial/intermediate - stage 1 and 2 of the a cross compiler to 
build from the 'host' to the 'sdk'.  Often the SDK is not the same target as the 
host.  (This is a 'native' binary.)


gcc-crosssdk - this the final stage of the SDK compiler.  Again, this is to 
build on the host, for the sdk.  This is a 'native' binary.


gcc-cross-canadian - This is the compiler included with the SDK to build on the 
SDK machine creating software for the target.  This is an 'nativesdk' package.



Is there any document for those description?


Not that I know of.. It's one of those things that you kind of need to know in 
order to work with it.  It likely should be documented somewhere officially.


--Mark




Best Regards,

Zhenhua


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



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

Re: [yocto] Difference of toolchain recipes

[Mark Hatle]

On 12/11/12 3:20 PM, Rifenbark, Scott M wrote:

I think what I am going to do is document these in general as part of the "Terms" section 
in the YP Development Manual where the term "Cross-Development Toolchain" is defined.  
Would putting such a high-level list in the YP documentation be unnecessary or helpful?


I think it would.  The set of compiler/toolchain elements we have is definitely 
confusing to someone new.


--Mark


Scott


-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-
boun...@yoctoproject.org] On Behalf Of Mark Hatle
Sent: Thursday, December 06, 2012 10:05 AM
To: yocto@yoctoproject.org
Subject: Re: [yocto] Difference of toolchain recipes

On 12/6/12 4:00 AM, Luo Zhenhua-B19537 wrote:

Can anybody shed some light, please?


Best Regards,

Zhenhua



-Original Message-
From: Luo Zhenhua-B19537
Sent: Tuesday, December 04, 2012 11:53 AM
To: openembedded-c...@lists.openembedded.org;

'yocto@yoctoproject.org'

Subject: Difference of toolchain recipes

It is a bit confused for the different recipes of toolchian, can

somebody

help to explain what's the difference for those recipes? E.g. gcc-

cross,

gcc-cross-canadian, gcc-cross-initial, gcc-cross-intermediate, gcc-
crosssdk, gcc-crosssdk-initial, gcc-crosssdk-intermediate, gcc-

runtime,

etc.


gcc-cross-initial - This is the initial compiler needed to bootstrap the
toolchain to build software on the host for the target.  (This is a
'native'
package.)

gcc-cross-intermediate - This is the second stage of the bootstrap
process to
build software on the host for the target. (This is a 'native' package.)

gcc-cross - this is the the final stage of the bootstrap process, and
results in
the cross compiler to build software on the host for the target.  (This
is a
'native' package.)  If you are replacing the cross compiler toolchain
with a
custom version, this is what you must replace.

gcc-runtime - these are the runtime libraries, but from the toolchain
bootstrapping process.  This results in a 'target' binary.

gcc-crosssdk-initial/intermediate - stage 1 and 2 of the a cross
compiler to
build from the 'host' to the 'sdk'.  Often the SDK is not the same
target as the
host.  (This is a 'native' binary.)

gcc-crosssdk - this the final stage of the SDK compiler.  Again, this is
to
build on the host, for the sdk.  This is a 'native' binary.

gcc-cross-canadian - This is the compiler included with the SDK to build
on the
SDK machine creating software for the target.  This is an 'nativesdk'
package.


Is there any document for those description?


Not that I know of.. It's one of those things that you kind of need to
know in
order to work with it.  It likely should be documented somewhere
officially.

--Mark




Best Regards,

Zhenhua


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



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


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

Re: [yocto] adding package management

[Mark Hatle]

On 12/12/12 5:43 AM, Burton, Ross wrote:

On 12 December 2012 11:31, Tim Coote  wrote:

Am I right in thinking that yum isn't in the standard recipes?


Yum, no.  Zypper is in oe-core and is used when you construct a RPM-based image.

(note that Zypper is being replaced by Smart in oe-core master)


See the following for more information on the change:
http://permalink.gmane.org/gmane.comp.handhelds.openembedded.core/29105

The one feature that Smart does not have that Zypper does (that I know people 
want) is delta-rpm support.  Otherwise it seems to be better for our uses in 
Embedded Systems.


--Mark


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



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

Re: [yocto] adding package management

[Mark Hatle]

On 12/12/12 6:07 AM, Tim Coote wrote:

ok. Thanks.

just spotted the split between rpm / rpm5 and yum. I suppose that the knock on 
is managing multiple repos for different update managers.

don't suppose you know if there are material differences from a 
packaging/dependency point of view between rpm4 and rpm5?


Generated packages are more or less compatible.  The only big difference is that 
all RPM5 packages are 'self-signed' to integrity purposes.  Self-signing is 
better then simply md5sums.  (They of course can also be signed with a specific 
key to indicate trust as well.)


But the primary difference is in cross compiling and support for the activities 
that we need when cross-constructing root filesystems and such.  There is also 
an aspect of 'control' behind this.  We have input into the RPM5 development, in 
RPM4 we have absolutely no influence and they have removed everything that 
helped in a cross-compiled environment after the split.



is there an eta for smart in the mainstream core?


Hopefully the next version of the integration patches should be sent up today. 
We're really trying to get the code in by next week.


--Mark


On 12 Dec 2012, at 11:43, "Burton, Ross"  wrote:


On 12 December 2012 11:31, Tim Coote  wrote:

Am I right in thinking that yum isn't in the standard recipes?


Yum, no.  Zypper is in oe-core and is used when you construct a RPM-based image.

(note that Zypper is being replaced by Smart in oe-core master)

Ross


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



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

Re: [yocto] What is GMAE?

[Mark Hatle]

On 12/14/12 1:46 PM, Burton, Ross wrote:

On 14 December 2012 19:43, Tim Bird  wrote:

"If you need GMAE, you should use the bitbake meta-toolchain-gmae command. The 
resulting installation script when run will support such development. However, if 
you are not concerned with GMAE, you
can generate the toolchain installer using bitbake meta-toolchain."

After googling a bit, I figured out that GMAE stands for Gnome Mobile and 
Embedded.

It might be good to put this acronym somewhere in the manual.
(I'm still not sure if I need GMAE or not...)


Basically, GMAE means GTK+ 2 and bits of the GNOME stack.

A stealth plan of mine is to remove every trace of GMAE from Yocto.
It was an initiative Poky was involved with back in the OpenedHand
days that didn't really take off, and we're still carrying pieces of
it.


I get this question a lot.  With the ability (new in 1.3) to build an SDK based 
on the contents of any arbitrary image.. the meta-toolchain-gmae is simply not 
necessary.


bitbake -c populate_sdk 

--Mark


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



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

Re: [yocto] What is GMAE?

[Mark Hatle]

On 12/14/12 4:12 PM, Tim Bird wrote:

On 12/14/2012 12:45 PM, Mark Hatle wrote:

On 12/14/12 1:46 PM, Burton, Ross wrote:

On 14 December 2012 19:43, Tim Bird  wrote:

"If you need GMAE, you should use the bitbake meta-toolchain-gmae command. The 
resulting installation script when run will support such development. However, if 
you are not concerned with GMAE, you
can generate the toolchain installer using bitbake meta-toolchain."

After googling a bit, I figured out that GMAE stands for Gnome Mobile and 
Embedded.

It might be good to put this acronym somewhere in the manual.
(I'm still not sure if I need GMAE or not...)


Basically, GMAE means GTK+ 2 and bits of the GNOME stack.

A stealth plan of mine is to remove every trace of GMAE from Yocto.
It was an initiative Poky was involved with back in the OpenedHand
days that didn't really take off, and we're still carrying pieces of
it.


I get this question a lot.  With the ability (new in 1.3) to build an SDK based
on the contents of any arbitrary image.. the meta-toolchain-gmae is simply not
necessary.

bitbake -c populate_sdk 


Aha.  Thanks very much.

Is this the preferred way to get a toolchain out of yocto?
That's exactly what I'm working on at the moment (well, after
fixing up some toolchain build issues I've encountered after
messing around a bit with the toolchain recipes...;-)


I don't know if it's the preferred "Yocto Project" way.. but it's the only way I 
do it.


The code was implemented in the middle of the 1.3 process and does work in 1.3. 
 (However multilib support may not be there.  There are a series of patches 
pending for master that do enable the multilib support as part of the rpm/smart 
work.)


--Mark


  -- Tim


=
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=

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



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

Re: [yocto] What is GMAE?

[Mark Hatle]

On 12/14/12 3:57 PM, Brian Hutchinson wrote:

On Fri, Dec 14, 2012 at 4:09 PM, Zhang, Jessica  wrote:

Actually I talked with Richard regarding retiring the toolchain targets 
(meta-toolchain and meta-toolchain-gmae) as Mark mentioned that now we can build a 
toolchain matching the >image.  Also, we're continue improving adt-installer which 
also allows you to setup sysroot using the target image as well.  Richard's concern 
is there maybe some legacy user that >preferred the toolchain target. With the 
latest changes in toolchain generation which really maps to target images, probably 
we should unplug to legacy ones to make the toolchain generation more streamline.  
Thoughts or concerns?


I'm one of the users that is stuck using Edison 6.0.  I'm desperate
for the ability to generate a toolchain and sysroot that matches our
target.  Right now I have to build meta-toolchain and then manually
look in the tmp for sysroot-destdir related stuff from our build and
copy it to the sysroot in /opt/poky and hand that out to developers.
When our sister group overseas makes a change that effects the sysroot
it breaks our build and I have to figure out what happened and
manually adjust our sysroot to fix the problem.  I sure would like to
be able to just do an update and then bitbake the toolchain to pick up
the changes.  I figure we are stuck with Edison for a while ... can I
back port these toolchain features you all are talking about to
Edison?


There are changes to both bitbake and oe-core required.  You'll have to look 
back at the oe-core mailing list to find the right set to backport.


We have backported the items to our 1.2 (7.0 Denzil) based system, but I'm not 
aware of anyone who is using it in 1.1 (6.0 Edison).


--Mark


Regards,

Brian



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

Re: [yocto] IMHO, cross-compile/toolchain examples should use non-x86 arches

[Mark Hatle]

On 12/16/12 4:57 PM, Sean Liming wrote:


My 2c (USD) is for clarity on ADT vs. SDK vs. Toolchain.


The biggest clarify problem I've seen is the terms being intermingled.  There 
are clear definitions for each.


Toolchain, the compiler and related tools that enable compiling software for a 
given target.


SDK - Software Development Kit - On OE-Core this purpose of this is to enable 
developing software to be run on a specific target environment, generally also 
constructed from OE-Core.  The SDK consists of three primary components:
  1) environment setup files - these configure the compilation environment with 
the right settings
  2) nativesdk software - these are applications that run on the -host- system 
to assist in compiling software for the target (this includes the target toolchain.)
  3) target sysroot - The sysroot is the collection of libraries, headers and 
assorted items that are compiled for the target.  A sysroot is setup in a 
similar fashion as a target's root filesystem.


ADT - Application Developer Tool - This is an Eclipse component that can use the 
SDK, generated by OE-Core, to enable application development within the Eclipse 
framework.  (I may be slightly wrong on this item, as people have told me in the 
past there are command line parts to the ADT but the ADT itself is -not- the 
SDK.)


--Mark


Regards,

Sean Liming
Owner
Annabooks
Tel: 714-970-7523 / Cell: 858-774-3176


-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-
boun...@yoctoproject.org] On Behalf Of Robert P. J. Day
Sent: Sunday, December 16, 2012 8:55 AM
To: Yocto discussion list
Subject: [yocto] IMHO, cross-compile/toolchain examples should use non-
x86 arches


   a general preference on my part, but i think it would be useful if any

yocto

docs that are discussing toolchains or cross-compilation or the like use
*non*-x86 architectures to get the point across.

   for example, consider the current application developer's guide.
part of it uses, as an example, the toolchain installer

poky-eglibc-x86_64-i586-

toolchain-gmae-1.4.sh.  while this works just fine, of course, what it

does is

potentially co-mingle both the dev host content and target host content,
making it harder than necessary for the reader to draw a clear distinction
between the two.

   if any example related to compilation or a toolchain involves, say, an

*arm*

target, then it's *immediately* obvious (using the "file"
command) whether something belongs on the dev host or on the target.

   also, if you're using x86 for both dev content and target content, you

run

the risk of an example working by accident since you're picking up

natively-

installed tools when you shouldn't be.  if you use a non-x86 arch, there's

little

chance of that happening.

   just my $0.02 (Cdn).

rday


--

==
==
Robert P. J. Day Ottawa, Ontario, CANADA
 http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday
==
==
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


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



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

Re: [yocto] where should "bitbake -c populate_sdk ..." be documented?

[Mark Hatle]

On 12/24/12 6:06 AM, Robert P. J. Day wrote:


   at the moment, the only mention of that task is in the reference
manual.  does it deserve additional coverage, perhaps in the ADT
manual?  just asking.


I would recommend any place that mentioned "meta-toolchain" or variants as a way 
to generate the SDK that can be used by the ADT tooling.


Since the goal of the populate_sdk task (when used with an image) is the same as 
the stand-a-lone SDK recipes.


--Mark


rday



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

Re: [yocto] Fix prelink build with automake-1.13

[Mark Hatle]

On 1/3/13 1:52 AM, Marko Lindqvist wrote:

[PATCH] fix build with automake-1.13.

Long obsolete AM_CONFIG_HEADER is completely removed from automake-1.13,
which errors out upon seeing it.
configure.in -> configure.ac rename is not strictly necessary yet,
use of deprecated name still gives only warning.

Problem in dropping obsolete constructs is that support for autotools
versions so ancient that now-obsolete way is the only way to do things.
configure.in seems to have AC_PREREQ(2.13), but with these changes
(if not earlier) such an ancient autoconf will not do.



Do you know if the change to AC_CONFIG_HEADER (from AM_CONFIG_HEADER) is 
supported in autoconf 2.13?  Assuming it likely is, I'll get this merged. 
Otherwise we should expect to bump the AC_PREREQ.


BTW I'll check and see if this patch is specific to the cross-prelinker or 
applicable to the upstream prelink as well.  Seems like if it's applicable there 
they may want it as well..


--Mark


  - ML



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

Re: [yocto] Fix prelink build with automake-1.13

[Mark Hatle]

On 1/3/13 10:00 AM, Mark Hatle wrote:

On 1/3/13 1:52 AM, Marko Lindqvist wrote:

[PATCH] fix build with automake-1.13.

Long obsolete AM_CONFIG_HEADER is completely removed from automake-1.13,
which errors out upon seeing it.
configure.in -> configure.ac rename is not strictly necessary yet,
use of deprecated name still gives only warning.

Problem in dropping obsolete constructs is that support for autotools
versions so ancient that now-obsolete way is the only way to do things.
configure.in seems to have AC_PREREQ(2.13), but with these changes
(if not earlier) such an ancient autoconf will not do.



Do you know if the change to AC_CONFIG_HEADER (from AM_CONFIG_HEADER) is
supported in autoconf 2.13?  Assuming it likely is, I'll get this merged.
Otherwise we should expect to bump the AC_PREREQ.

BTW I'll check and see if this patch is specific to the cross-prelinker or
applicable to the upstream prelink as well.  Seems like if it's applicable there
they may want it as well..


Responding to my own query.  I just checked and the cross-prelinker is already 
setup for AC_PREREQ(2.50):


http://git.yoctoproject.org/cgit/cgit.cgi/prelink-cross/tree/trunk/configure.in?h=cross_prelink

(The unmodified upstream -- master branch -- is still using AC_PREREQ(2.13). 
But we don't use that in OE/Yocto Project work.)


The -- cross_prelink branch -- does still have the AM_CONFIG_HEADER.  I'll get 
that updated.  I will also rename the configure.in to configure.ac and adjust 
anything else that references that.


--Mark


--Mark


   - ML





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

Re: [yocto] configuration management on remote target

[Mark Hatle]

On 1/3/13 5:43 PM, Ilya Dmitrichenko wrote:

Hi,

As my day job mostly involves configuring servers using puppet configuration
management system, I had been thinking of what sort of tool would be best to use
on an embedded devices where on some occasions one would want to update a couple
of config files and scripts. Perhaps this can be limited just to the `/etc`
direcotry...

So the best I could come up with so far is to implement it as cron job that
would pull a git repository, perhaps it would also run a script (git hook) that
would restart a daemon or do something of that kind.

I suppose that some people will suggest to just use packages, but I'm not very
keen on maintaining a package repository on some sever out in the internet that
would be one big single point of failure. Although, perhaps, on some occasion,
this may be the only way.
Another reason why I wouldn't like to use git to manage configuration, as that
way all configs are going to be at hand from one directory tree, which is, IMO,
much quicker to manage and validate rather then a recipes spread across
subdirectories.


There are different systems out there that need to be managed (as well as 
different philosophies of how to manage them.)  Solving all of the problems 
isn't going to work.  Solving a specific problem has a chance.  :)


It's fairly typical that a device can be maintained as files, packages, or 
filesystem images.  Each of those approaches requires a very different 
upgrade/maintenance mechanism.  In addition since embedded systems do not have 
an admin console, if they fail during the upgrade process you can brick a user, 
so a fail safe is almost always required!


In each of the above methods, you can do things like transfer an individual file 
(or files) and related reset commands after an upgrade has occurred.. send up a 
package (or packages) and automate that -- or even upgrade the filesystem, but 
in each of these cases bandwidth may be at a premium.  Most field upgrade 
systems want a "delta" (diff) based system, where only the changes have to be 
sent, not the whole file.



Firstly, I'd appreciate any feedback on this!

And I do have a few rather more specific questions ;)



a) How often OE users do not implement any system updates over the wire in their
products, although the product is able to access the internet?


Due to the complexity of upgrading, this is fairly typical on embedded systems 
in my experience...but it's being tolerated less and less over time.  (They 
usually have some kind of an upgrade mechanism, they just don't do it over the 
internet.)



b) Has anyone here use the configuration tools like puppet, chef or cfendgine
and understands the benefits?

c) Has anyone succeeded building git without having to include perl on the
target? I'd probably get ways with just a subset of git commands.
I have also had a look at libgit2, but not sure if I'd be able to implement
something as robust as git itself with libgit2...


Last time I looked (a few months back) it was not possible to build a functional 
git system w/o perl -- or at least I wasn't able to.  I hope this continues to 
get better, as perl is -very- heavy weight for an embedded system.



So if you want the ultimate works for everyone system.. it really needs to be a 
field upgrade tool of some kind.  Basically providing the infrastructure to 
push/pull the update, a way to use a delta of the update to what is already 
installed on the device to construct the "file" to save bandwidth, a way to 
apply the update and control the associated behavior.  Then people can use that 
to implement file, package or image based upgrades... fail safe behavior is also 
usually device specific and would be implemented based on the toolkit.




Cheers,
--
Ilya



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



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

Re: [yocto] Bitbake and task offloading onto multiple cloud-based servers

[Mark Hatle]

On 1/4/13 2:56 PM, Alex J Lennon wrote:


Can anybody advise on whether bitbake currently supports offloading of
build tasks onto multiple systems? Perhaps cloud based?


I see Chris Larson has already answer the main question here.. but I've got some 
additional insight I can add.



I'm thinking that it would be more efficient for me if I could bring up
a number of Amazon EC2 servers (or similar) then have bitbake
parallelise the build onto those servers to significantly reduce my
build times?


In the past I've had people ask me questions about remote builds, parallel 
building packages, etc.  In the past when I've attempted to figure out if it 
would be useful, the cost of the data transfer time always comes into play.  How 
long does it take to simply perform the task locally vs go to the remote 
machine, perform the task, and get the data back.  For a lot of the tasks that 
OE does, the remote tasks will end up being slower on a reasonably modern i7 (or 
similar Xeon) machine.  I'm not sure using something like a cloud server would 
end up helping due to this.


From experience I'd say that if anything you'd likely want to modify the 
bitbake scheduler with some type of locality information.  I.e. if you extract 
the sources on a node, you most likely want to patch, configure, compile, 
install, QA and package on that node as well but that also means a way to 
establish node specific tmp/work space is needed for performance as well.



I see bitbake supports a level of task parallelisation on a single box.

Can parallelisation of build onto multiple systems be achieved?


All of the above are possible, but I suspect there is a lot of design and 
refactoring required to come up with a system that is both efficient and fast.



Is it something that should even be a goal?


It's not currently a goal.  But it does get asked about every now and then.  It 
would be nice to have something more then anecdotal information about if it 
would be a good idea or not.  This is the type of thing that I think would make 
an excellent research project.  (Hey and if it makes things able to be built for 
more people, faster, and cheaper great!  If not, we'd have a more informed 
response to questions like this.)


--Mark


Cheers,

Alex

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



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

Re: [yocto] are separate -sdk image targets necessary Was: Build external module against Yocto kernel

[Mark Hatle]

On 1/23/13 10:56 AM, Burton, Ross wrote:

On 23 January 2013 16:51, Trevor Woerner  wrote:

On Tue, Jan 15, 2013 at 2:16 PM, Zhang, Jessica  wrote:

According to bug 1614, the kernel dev packages should be
included in sdk images. Please generate your toolchain using
"bitbake core-image-sato-sdk -c populate_sdk" which will
make the toolchain target sysroot matching your image's
sysroot (this is a new feature of 1.3) as long as your image
is a sdk image.


I am a bit confused by the above email. To me it appears as if Jessica
is saying: "add '-c populate_sdk' to the build of an -sdk image".

But if we look at this email from Mark Hatle:
http://www.mail-archive.com/yocto@yoctoproject.org/msg10636.html

I get the impression that Mark is saying: "now that '-c populate_sdk'
is available, there no longer is any need for separate -sdk images".

Am I confusing two different things with each other?


My understanding was that populate_sdk will take the package set from
an image, add compilers and all development packages, and produce a
SDK.  So all you need is your production image, and then you can
generate a SDK from that.


That is correct.  Just like everything else in OE, there are multiple ways to do 
things.


When it comes to the SDK there are two main ways, an SDK specific recipe, such 
as meta-toolchain, or use an existing image and produce an SDK for that image. 
The former is better for targeted SDKs that you want to allow something to 
produce software with a known set of limitations/capabilities.  The later is 
useful when your SDK has to match the image -exactly-.


The kernel components/headers is a separate issue.  The SDKs are currently 
configured to be focused on application development tasks.  Jessica and I were 
talking this morning, and it may be possible to enable kernel module compilation 
as well -- but this isn't the existing use-case.


--Mark


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



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

Re: [yocto] TUNE_PKGARCH for Microblaze

[Mark Hatle]

On 3/26/13 1:12 AM, Sipke Vriend wrote:

Hi all,

With help from Khem's email we have been able to perform 'some' sanity
checking against the microblaze architecture.

The TUNECONFLICTS assist us in ensuring conflicting features are flagged during
the bitbake sanity check, however because Microblaze's features are
independently configurable, we would like to do some additional 'sanity
checking'.

Using a hierarchical method of features, like in arm, is not really viable for
Microblaze, so if there are alternate existing ways we would like to use them
rather than creating localised bb classes to do this for us.

1. Is there a way similar to TUNECONFLICTS for "paired" features, i.e. if one
feature exists another must also?
(Certain microblaze versions must have a set of features if a particular
feature is enabled).


The values in the conflicts can be adjusted programatically.  It may be what you 
need in this case.  Use inline python such as:


TUNECONFLICTS[foo] = "${@bb.utils.contains("TUNE_FEATURES", "some_feature", 
"conflict_if_set", "conflict_if_not_set", d)}"



2. Is there a way to define that certain features must exist, other than
defining multiple machines   (e.g. in endian case we would like to ensure 
one
of them is picked)?


You can add a bit of python code that can again use the contains item.  The code 
may need to be in a custom class though to execute.


python() {
if :
if :
bb.fatal("You must select an endian")
}


3. Additionally (or instead of 1 and 2) is there a way we can introduce/append a
'sanity check' into the bitbake layer model - i.e. inform bitbake to
run 'our complex sanity' check?


See above.. it will require a custom class.. you can make your tunes/arch file 
include the class using INHERIT += "your_class.bbclass".



As a continuation from my last email, the following is a list of possible 
Microblaze
architecture features, which can be supplied in the machine and/or local.conf
file. Lack of  a hardware feature means the soft version is used.

big-endian/little-endian
vXXX where XXX is a microblaze version (like v830)
barrel-shift
multiply-high multiply-low
pattern-compare
reorder
divide-hard
fpu-hard fpu-hard-extended

Additionally we plan to modify the package name slightly, e.g.
microblazeel-v840-bs-ml-div-fe-cmp-re
microblazeel-v830-bs-mh
microblazeel-v830


I think it's a good idea to have some standard tunes with functionality that is 
reasonable for a testable demo environment.  If the developers want to tailor it 
further, they should be able to either by manually selecting the features or 
creating a custom tune file.


This was the intent when the original tune system was introduced.  There was no 
way we would know every possible combination, so making a way the developer 
could specify it was the best answer we could come up with.  The TUNE_FEATURES 
adds the ability for the compiler and other packages to dynamically switch based 
on whatever the developer has configured.  It can be used for blacklisting code, 
changing optimizations, etc.


--Mark


Regards
Sipke


On Mar 20, 2013, at 4:44 PM, Khem Raj  wrote:


On Mar 19, 2013, at 9:08 PM, Sipke Vriend  wrote:


Hi all,

We are seeking some feedback regarding common practices for defining 
TUNE_PKGARCH within Yocto.


usually its dictated by architecture, ABI and other processor features. the 
current tune files have good ways to express the relationships
you would translate the below table into set of TUNE_FEATURES and define 
PACKAGE_EXTRA_ARCHS if you need to express compatibility between different tunes

Look at arm tunes they are the best examples of complexity


We need to define a unique TUNE_PKGARCH for the possible configuration of 
Microblaze architecture.
Our proposal is short unique string for each HW feature which is enabled in 
Microblaze.

For 'extensive hardware usage' architecture, this would result in something 
like:
mbebv730-bs-mh-div-fb-cmp
mbebv840-bs-mh-div-fb-cmp-re
mbelv840-bs-ml-div-fe-cmp-re
and for architecture with no 'hardware usage':
mbebv730
mbebv840
mbelv840

The table below details the unique strings and their relation to compiler and 
hardware flags, and a couple of versions of Microblaze architecture.
(If this table does not show cleanly switch to fixed width font)
---
String Compiler FlagHardware Flag CPU versions
   -mcpu=vX.YY.Z  v7.30.a v8.40.a

mbel   -mlittle-endian  C_ENDIANNESS (LITTLE) -   o
mbeb   -mbig-endian C_ENDIANNESS (BIG)x   o

bs -mxl-barrel-shiftC_USE_BARREL  o   o

ml -mnoxl-soft-mul  C_USE_HW_MUL (MUL32)  o   o
mh -mxl-multiply-high   C_USE_HW_MUL (MUL64)  o   o

div-mnoxl-soft-div  C_USE_DIV o   o

fb -mhard-float C_USE_FPU (BASIC) o   o
fe -mxl-float-convert   C_USE_FPU (EXTENDED)  o   o
fe 

Re: [yocto] Building "restricted" source code

[Mark Hatle]

On 3/26/13 7:53 AM, Jerrod Peach wrote:

As part of my company's firmware builds, we have to build some code that only a
handful of developers are allowed to view.  We call this restricted source code.
  Getting our official "system" builds to build this code isn't a problem.  What
is a problem is a regular developer's build of this code.

Imagine this scenario: The restricted source depends upon eglibc.  Our low-level
team, who doesn't have access to the restricted source, updates the recipe for
eglibc.  The hash for the restricted package is permuted, and so they can't get
an sstate hit and are required to rebuild the source.  But, since they can't
check out the source, they can't build it.  This would cause a build failure.

Is anyone dealing with this scenario while using Yocto currently?  If so, how?
  I know it may be unlikely that many people are hitting this since Yocto is
primarily used to build open-source code, but I thought I'd take a shot in the
dark and hope for the best.  :-)



Two ways I know of doing this.  Slightly different way of doing things:

1) If the code does -not- rely on outside influences, such as eglibc.  Configure 
the recipe and pretty much ignore everything else with a vardepsexp.  Then ship 
the sstate-cache files that cover the compiled code.  (Along with the original 
recipe...)


2) For code that DOES rely on outside influences.. create a custom recipe that 
either downloads the source and builds it [if the user has access to the 
source], or will pull the binaries from a specific location and simply 
install/package them.   This is actually the more common approach.


(To seed that location, you can extract the items from your restricted build -- 
or build it outside the tree using an SDK or similar.)


--Mark


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



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

Re: [yocto] Shared DL_DIR with other users

[Mark Hatle]

On 3/26/13 9:25 AM, Paul Eggleton wrote:

Hi Simon,

On Tuesday 26 March 2013 14:37:36 Vanveerdeghem, Simon wrote:

We are using Yocto with a couple of users, to prevent that our build
server has duplicates of downloads, we share the DL_DIR.

But we have problems with permissions. When a user run yocto, it will
checkout sources, or download tar files with permissions 644 with the
username of the user who is running yocto.

When another user will do a cleanall of a bitbake recipe, yocto will
remove the tarball and the svn workingcopy, but because the permissions
aren't 777 It cannot remove all the files (yocto doesn't throw an error
here).

When that other user will do a fetch of thqt recipe, yocto will checkout
the svn directory, it will leave as good as clean because it says
internally "Skipped ." (yocto doesn't throw an error here) then it wil
take a tarball of it, again the tarball has only a directory named of
the checked out module, but have no sources. (yocto doesn't throw an
error here)

When yocto will building the sources it will fail because the tar was
clean, and there is nothing to build.

The rootcause of this problem is that the shared download directory only
use 644. (We can workaround this with the .profile (we can set in the
.profile a standard permission mask, but then you always use that mask,
something we don't want)


It's likely that sharing DL_DIR directly between multiple users is not a
heavily tested scenario. One way around it which is fairly widely used
though is to set up a local mirror shared by all of the build machines
and keep DL_DIR separate on each machine. There is some information on
how to do that here:

https://wiki.yoctoproject.org/wiki/How_do_I#Q:_How_do_I_create_my_own_source_download_mirror_.3F


This is how we do it.  We have one user who routinely does a fetchall against 
the trees and populates the mirror.  Then the users have a layer which adds:


PREMIRRORS_append = "\
 git://.*/.* file://path/ \n \
 svn://.*/.* file://path/ \n \
 ftp://.*/.* file://path/ \n \
 http://.*/.* file://path/ \n \
 https://.*/.* file://path/ \n \
"

--Mark


Cheers,
Paul



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

Re: [yocto] Compliance program questions

[Mark Hatle]

On 4/25/13 10:36 AM, Nicolas Dechesne wrote:

Hi there,

I have a couple of questions regarding the compliance program. If
there is a better place for asking such questions, please let me know.

I have studied the Yocto compliance documentation, [1] on the website,
and I have the following questions:


Below are my opinions, but I've been working on compliance issues for a while on 
our products.



  - is there any 'practical' guide with "do's and don'ts" to help make
a sucessful Yocto Project Compatible registration?


There probably should be.  I see Jeffro has already responded about this.


  - i understand that while the project should build with the OE core
toolchain, it is not required to use the OE core toolchain 'by
default', so we should be able to provide our own modified/customized
toolchain in our layers, is my understanding correct?


The intention is that you aren't doing anything that will make it difficult to 
work with the oe-core toolchain.  But we understand that new architectures may 
require a custom toolchain.  Also custom toolchains may be provided by the 
vendor for optimization and other reasons.  When I do my testing my rule is, 
everything must build with the oe-core toolchain, unless it's not implemented or 
has the same bug in the community.  (Not implemented is the case where an 
optimization or architecture doesn't existing in oe-core.)



  - it is recommended, but not mandatory not use the Yocto kernel, so
we can use any mainline version in our BSP layers, right?


You can, but I've been told this is in the process of being revised.  The reason 
for using the Yocto Project kernel is that it provides a common foundation for 
YP participants.  This common foundation should allow people familiar with the 
kernel tooling to make better use of the kernel sources and do things in a more 
reusable way.  It's only recommended currently because it's clear that the 
overall embedded community was not ready to embrace the tooling and versions 
selected by the Yocto Project at the time the guidelines were written.



  - is it tolerated to change the versions of some components from
OE-core or meta-oe? Not just add patches through .bbappend, but
actually use an older or a more recent version of components, let's
say Gstreamer for example?


If you change an upstream repository, oe-core, meta-oe, meta-yocto, etc.. You 
should submit the patch to the appropriate upstream.  If the 'change' has been 
backported from a newer version then it's already been submitted upstream. 
(Good process here is to document the commit ID of what you backported, so it's 
easy to show compliance.)


This holds true on .bbappends and new versions of things.  Note: if you put your 
new version of the code in your own custom layer, you don't need to submit it 
upstream for compliance.  (But I recommend you do as it will make long term 
maintenance much easier!)



  - can we included new recipes for software programs not already
included in oe-core or meta-oe in our layers, or do we have to
contribute them back into oe-core or meta-oe before registration?


Your layers are your own responsibility.  There is nothing that forces you to 
provide anything in your layer to an upstream location.  You just have to verify 
that it works with a suitable version of oe-core.


The contribution requirement is geared toward people who repackage oe-core and 
other open source layers for their customers.  It will help ensure that someone 
isn't hiding or playing games with their local version of oe-core to make it 
incompatible with other versions.  (Sure they can do that, but whatever they did 
to make it incompatible will have at least been sent to the public.)



  - the Yocto project compatible registration is made against a
specific version of Yocto. What happens when a new Yocto version is
released? Should we go through the registration process again?


Yes.  The registration process will have to be repeated.

--Mark



thanks a lot!

nicolas


[1] https://www.yoctoproject.org/ecosystem/yocto-project-compliance-program
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto



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

Re: [yocto] Finding/Generating Rootfs Package List

[Mark Hatle]

You can use the license manifest to give you this information.  See:

build/tmp/deploy/licenses/--/...

There is a license.manifest and package.manifest.  The license.manifest includes 
package version.


--Mark

On 4/25/13 9:10 AM, Jon Szymaniak wrote:

Hi all,

I generally like to keep a little manifest file with my rootfs images,
containing a list of installed packages and their associated versions.  On
images where I keep package data around, I usually generate this via 'opkg 
list'.

In my current situation, I have a small read-only image where I can't afford to
ship pkg data, and wanted to gather this info on the host side of things.  I
assume this information is tracked somewhere in the poky build directory, but
I'm having some trouble finding it.

Could someone kindly point me towards this information or the documentation
section(s) that I may have overlooked.

Thank you!
Jon


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



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

Re: [yocto] [PATCH] libsemanage: drop flag: -Wno-unused-but-set-variable

[Mark Hatle]

On 5/1/13 6:02 PM, Randy MacLeod wrote:

On 13-05-01 12:12 AM, Khem Raj wrote:


On Apr 30, 2013, at 8:15 PM, Randy MacLeod  wrote:


The flag: -Wno-unused-but-set-variable isn't supported on older
versions of gcc such as gcc-4.1.2 which is the native compiler for
RHEL-5.9. Drop this warning flag for both the native and target builds.



why drop from target build ?


I thought I'd have to create a separate -native recipe and
that didn't seem to be worthwhile for this warning flag.

On the other hand, the recipe is tiny so I could fix it up
if you think it's important. Oh and I should fix the _git
version of libselinux too.


You can selectively add the patch to the SRC_URI only in the class-native case.

SRC_URI_append_class-native = " "

I believe that will work as expected.

--Mark


// Randy




Signed-off-by: Randy MacLeod 
---
...semanage-drop-Wno-unused-but-set-variable.patch |   17 +
recipes-security/selinux/libsemanage_2.1.9.bb  |6 --
recipes-security/selinux/libsemanage_git.bb|6 --
3 files changed, 25 insertions(+), 4 deletions(-)
create mode 100644 
recipes-security/selinux/libsemanage/libsemanage-drop-Wno-unused-but-set-variable.patch

diff --git 
a/recipes-security/selinux/libsemanage/libsemanage-drop-Wno-unused-but-set-variable.patch
 
b/recipes-security/selinux/libsemanage/libsemanage-drop-Wno-unused-but-set-variable.patch
new file mode 100644
index 000..faf8fc5
--- /dev/null
+++ 
b/recipes-security/selinux/libsemanage/libsemanage-drop-Wno-unused-but-set-variable.patch
@@ -0,0 +1,17 @@
+Subject: libselinux: drop flag: -Wno-unused-but-set-variable
+
+Upstream status: inappropriate (older compilers only).
+
+Signed-off-by: Randy MacLeod 
+
+--- libsemanage-2.1.9.orig/src/Makefile
 libsemanage-2.1.9/src/Makefile
+@@ -57,7 +57,7 @@
+ LOBJS= $(patsubst %.c,%.lo,$(SRCS)) conf-scan.lo conf-parse.lo
+ CFLAGS ?= -Werror -Wall -W -Wundef -Wshadow -Wmissing-noreturn 
-Wmissing-format-attribute
+
+-SWIG_CFLAGS += -Wno-error -Wno-unused-but-set-variable -Wno-unused-variable 
-Wno-shadow \
++SWIG_CFLAGS += -Wno-error -Wno-unused-variable -Wno-shadow \
+   -Wno-unused-parameter
+
+ override CFLAGS += -I../include -I$(INCLUDEDIR) -D_GNU_SOURCE
diff --git a/recipes-security/selinux/libsemanage_2.1.9.bb 
b/recipes-security/selinux/libsemanage_2.1.9.bb
index 0e0bc41..3b1d8db 100644
--- a/recipes-security/selinux/libsemanage_2.1.9.bb
+++ b/recipes-security/selinux/libsemanage_2.1.9.bb
@@ -1,4 +1,4 @@
-PR = "r0"
+PR = "r1"

include selinux_20120924.inc
include ${BPN}.inc
@@ -11,4 +11,6 @@ SRC_URI[sha256sum] = 
"6f01d17f9751412f7b76e6e7daafeb2faf301b9bfeea83506160c81bec
SRC_URI += "\
file://libsemanage-Fix-execve-segfaults-on-Ubuntu.patch \
file://libsemanage-fix-path-len-limit.patch \
-   file://libsemanage-fix-path-nologin.patch"
+   file://libsemanage-fix-path-nologin.patch \
+   file://libsemanage-drop-Wno-unused-but-set-variable.patch \
+   "
diff --git a/recipes-security/selinux/libsemanage_git.bb 
b/recipes-security/selinux/libsemanage_git.bb
index 562512c..b3819a0 100644
--- a/recipes-security/selinux/libsemanage_git.bb
+++ b/recipes-security/selinux/libsemanage_git.bb
@@ -1,4 +1,4 @@
-PR = "r4"
+PR = "r5"
PV = "2.1.6+git${SRCPV}"

include selinux_git.inc
@@ -10,4 +10,6 @@ SRC_URI += "file://Fix-segfault-for-standard-policy.patch \
file://libsemanage-Fix-execve-segfaults-on-Ubuntu.patch \
file://libsemanage-semanage.conf-for-cross-compile.patch \
file://libsemanage-fix-path-len-limit.patch \
-   file://libsemanage-fix-path-nologin.patch"
+   file://libsemanage-fix-path-nologin.patch \
+   file://libsemanage-drop-Wno-unused-but-set-variable.patch \
+   "
--
1.7.4.1

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







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

Re: [yocto] SRPMs

[Mark Hatle]

On 5/7/13 1:28 PM, Post, Travis wrote:

Is it possible to create source RPMs from Yocto? If so, is there any
documentation or guidance on how to do this? I’ve found a bug that was closed
mentioning:

INHERIT += "archive-patched-source"

SOURCE_ARCHIVE_PACKAGE_TYPE = "SRPM"

However, this results in an error referencing get_package. When I add: “inherit
archiver”, this changes to an error referencing undefined variable ‘f’.


At one point we had the system so it would generate an SRPM.  But you have to 
remember the SRPM is just a container, this isn't going to build something you 
can bring to your favorite RPM based distribution and build.


The code would take the configure/compile/install steps and dump them into the 
spec, along with references to the source and patches.  This way everything was 
in one convenient place, but again -- it's not going to work standalone.


To build software for the YP, you really need to use the build environment -- or 
an SDK.


--Mark


Thanks,


Travis



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



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

[yocto] [RFC] eglibc / glibc and option-groups being deprecated?

[Mark Hatle]

Recently on the eglibc mailing list there has been a discussion about removing 
the option groups.  See: http://www.eglibc.org/archives/patches/msg01268.html


For folks who don't know what option-groups are, it's a patch that went into 
eglibc a number of years ago that allows you to disable various components 
(effectively altering the API) in order to shrink the size of glibc.


It was created as an attempt to get into glibc the same type of configuration 
ability that uclibc has.


In OpenEmbedded Core, it is currently being used to enable the ability to shrink 
the LibC footprint to a smaller size.  The Yocto Project's Poky-tiny 
distribution uses it as part of the mechanism to create a smaller filesystem.


I encourage you to read the original thread, and if it affects you, please speak 
up.  The following is my attempt at summarizing the thread.


Currently the maintainer(s) of eglibc are working on syncing up glibc and eglibc 
to the point that there will no longer be a need for eglibc.  (See 
http://www.eglibc.org/archives/patches/msg01261.html)


EGlibc was originally developed to house various architecture ports and other 
embedded friendly features were not allowed into glibc.  The majority of the 
differences between eglibc and glibc have disappeared, with only a few major 
exceptions.  One of which is the option-groups support.  This item is taking a 
significant amount of resources to keep up to date, and it's unclear as to the 
number of users for this functionality.


The belief of the maintainers is that the days of truly small footprint systems, 
where even 1 MB of storage was a large number are coming to an end.  As such, 
the time and effort to maintain the option groups is likely not worth the effort.


I expect that between OpenEmbedded and the Yocto Project, a large percentage of 
the users would be represented in some way.  But beyond that, I don't have any 
idea as to how many people actually benefit from this technology.


During the discussion the results were that either assistance with maintaining 
the option-groups is needed, or the feature will be deprecated and eventually 
removed.  The last part of the thread it was suggested that in eglibc 2.19 it 
would be deprecated, and then removed in 2.20.


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

Re: [yocto] Bitbake requires Python 2.7.3

[Mark Hatle]

On 6/28/13 5:53 AM, Burton, Ross wrote:

On 28 June 2013 11:16, Paul Barker  wrote:

Just chiming in to say that sounds excellent. Will this contain a
known-working make as well for those with a broken make 3.82?


What systems have a broken 3.82?  I'm aware that Debian Experimental
has it, but stable/testing/unstable have a working 3.81.  Certain
older versions of Suse also had a broken 3.82, but they've been fixed
recently after I filed some bugs.  Is it just Fedora 16?


Fedora 16 and newer
Arch Linux
Debian Experimental

I wouldn't be surprised if there are others.

(I filed a bug for Fedora, so FC 18 and FC 19 will be fixed if they're not 
already.)

Someone on the OE-Core list said they would file a bug on Arch Linux.

--Mark


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



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

Re: [yocto] [OE-core] OpenEmbedded eV membership drive

[Mark Hatle]

Speaking as a member of the TSC, our understanding is an election would be
called for the first position at the beginning of May.  (More or less this 
week.)

The TSC members up for election was decided by the TSC to be in the order of the
original board announcement, with the final two members going up for election at
the same time.

--Mark

On 5/3/11 3:05 PM, Frans Meulenbroeks wrote:
> 2011/5/3 Philip Balister 
> 
> [...]
> 
>>
>> People ask me why they should join the eV. Besides being a good way to show
>> your support for the OpenEmbedded project, the Technical Steering Committee
>> is elected by the eV members.
>>
>> Sorry but the current TSC is NOT elected by the eV members.
> 
> Actually the board even fails to meet its own "rules" stipulated when they
> installed this interim TSC.
> 
> From Philip's email from feb 10:
> 
> This interim TSC will operate for 2 months when we shall start elections
> at two month intervals for the 5 positions on the TSC. The new elected
> TSC members will operate under the charter detailed on the wiki here
> http://wiki.openembedded.org/index.php/TSCCharter.
> 
> We're now almost 3 months later and no election has been held!
> 
> Frans
> ___
> Openembedded-core mailing list
> openembedded-c...@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

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

Re: [yocto] Agenda: Yocto Technical Team (Tuesday, June 21, 2011 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada))

[Mark Hatle]

Yes.  It seems like some mailers lost the dial-in info.

Toll-Free 1-877-561-6828 (US)
Toll 1-972-995-

Participant Code  49611427

--Mark

On 6/28/11 10:08 AM, Denys Dmytriyenko wrote:
> On Fri, Jun 17, 2011 at 10:16:47PM +, Liu, Song wrote:
>> All,
>>
>> In order to make the meeting more effective, I would like to suggest that we 
>> use the following status categories to track the status of each feature:
>>
>> 1.   Design (still in design stage)
>> 2.   Design Review (who is reviewing it)
>> 3.   Development (if you can tell the % completed so far, it would be great. 
>> If it's too hard, don't bother)
>> 4.   Patch Review (Patch sent out for review)
>> 5.   Done (checked into master)
>>
>> At the same time, we can certainly talk about blocking issues and any help 
>> you would like from the team. Let me know if you have any suggestions or 
>> would like to add anything to the Agenda.
>>
>>
>> Agenda:
>>  
>> - Review Yocto 1.1 M2 schedule and Release Criteria - 20 min (Song)
>> See details at: 
>> https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.1_Release_Criteria 
>> - Go over Sprint C items - 20 min (Song)
>> - Opens - 10 min
>>
>>
>>
>> Tuesday, June 21, 2011, 08:00 AM US Pacific Time 
>> 916-356-2663, 8-356-2663, Bridge: 94, Passcode: 7964061
>> Speed dialer: inteldialer://94,7964061 | Learn more
> 
> Hi,
> 
> Is there a meeting today (June 28th) and was the new bridge information 
> published anywhere?
> 

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

Re: [yocto] Getting pseudo from yocto/poky toolchain working with my build

[Mark Hatle]

On 6/28/11 5:50 PM, Richard Purdie wrote:
> On Tue, 2011-06-28 at 18:29 +0100, O'donoghue, Bryan wrote:
>> ASSUME_PROVIDED += "m4-native tcl-native gettext-native libtool-native
>> quilt-native autoconf-native automake-native perl-native
>> sqlite3-native tar-replacement-native pseudo-native"
> 
> I don't know about the pseudo issue, the system really wasn't designed
> to allow for a system provided pseudo since few systems would actually
> have that.

pseudo is expected to be built for each build directory and each host system.
It's a VERY small binary so it should be quick... (you may be required to have
sqlite3 from the build though, the problem you have might simply be you can't
use the "host" version for pseudo this could be an enhancement request.)

We build pseudo for every host / build directory, because it has to learn the
system capabilities, and specifically the glibc capabilities in order to
determine what functions to intercept.  Unfortunately different versions of
glibc require slightly different intercepting code.

> I'm almost certain you're going to hit issues with the line above from
> perl-native, libtool-native and autoconf-native and automake-native
> though as you won't have key patches applied.
> 
> Cheers,
> 
> Richard
> 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

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

Re: [yocto] Getting pseudo from yocto/poky toolchain working with my build

[Mark Hatle]

On 6/29/11 2:17 AM, O'donoghue, Bryan wrote:
> Saul, Richard.
> 
> Thanks for the suggestions re: building the whole thing from scratch.
> 
> In a previous life using openembedded our solutions for slow builds were an 
> array of ASSUME_PROVIDEDs. I'll try the build the world approach instead !
> 
> Saul I'll send you along the logfiles off-list, one thing is that the build 
> process looks for 
> 
> ASSUME_PROVIDED += "sqlite3-native"
> /home/deckard/Development/yocto/poky-5.0.1-build/tmp/sysroots/i686-linux/usr/include/sqlite3.h
> Instead of /usr/include/sqlite3.h !

I don't have time to implement/try this right now.. but one suggestion would be
to change the meta/recipes-devtools/pseudo/pseudo.inc so that the configure
calls pass the location of sqlite conditionally.  Currently it's using:

--with-sqlite=${STAGING_DIR_TARGET}${exec_prefix}

Simply checking for the existance of
${STAGING_DIR_TARGET}${include_prefix}/sqlite3.h and only passing --with-sqlite=
should be enough.  (it will fall back to the host otherwise.. and if the host
version is not sufficient it will error.)

--Mark

> 
> Bryan
> 
> -
> Intel Ireland Limited (Branch)
> Collinstown Industrial Park, Leixlip, County Kildare, Ireland
> Registered Number: E902934
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

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

Re: [yocto] RPM multilib package installation issue

[Mark Hatle]

On 9/2/11 2:33 AM, Xu, Dongxiao wrote:
> Hi Mark and Richard,
> 
> I am trying to setup a RPM multilib system that, it is a qemux86-64 base
> image with MULTILIB_IMAGE_INSTALL = "lib32-connman-gnome". With several
> fixes, the build can pass.
> 
> However in run time testing I met a problem that, for those libraries whose
> base/multilib versions packages will be both built out (like libgtk, it has
> "libgtk-2.0-2.22.1-r2.x86_64.rpm" and "libgtk-2.0-2.22.1-r2.x86.rpm"), the
> rpm will only installs the lib32 version of it.

During filesystem construction the system uses dependencies to decide what to
install.  If you build a 32-bit connman-gnome and it requires other 32-bit
libraries the dependency scanner will either pick them up and install them, or
error due to missing dependencies.

In the manual case you would use "rpm -Uhv " manually specifying which one
you want.  RPM will detect a multilib package and will allow installation of
both versions.  (Note always use rpm -U and not rpm -i..  rpm -i just blindly
installs the software with no checking if an existing version exists.)

> Therefore one question is, if there are two rpm packages with the same PN,
> PV, PR, but different architecture (like our multilib case), then we run
> command "rpm -ivh libgtk", which version of libgtk will be installed? Or does
> rpm have any parameter to force installing them both? Actually multilib
> requires to install them both with certain order.

No specific order should be necessary on a multilib system.  As long as the end
dependencies are satisfied the resulting filesystem will work.  (Exceptions to
this are when there are pre and post install scripts that have their own unique
dependencies.. but those are not the normal case for OE-Core/Yocto.)

--Mark

> Thanks, Dongxiao
> 

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

Re: [yocto] RPM multilib package installation issue

[Mark Hatle]

On 9/2/11 10:40 AM, McClintock Matthew-B29882 wrote:
> On Fri, Sep 2, 2011 at 10:03 AM, Mark Hatle  wrote:
>>> However in run time testing I met a problem that, for those libraries whose
>>> base/multilib versions packages will be both built out (like libgtk, it has
>>> "libgtk-2.0-2.22.1-r2.x86_64.rpm" and "libgtk-2.0-2.22.1-r2.x86.rpm"), the
>>> rpm will only installs the lib32 version of it.
>>
>> During filesystem construction the system uses dependencies to decide what to
>> install.  If you build a 32-bit connman-gnome and it requires other 32-bit
>> libraries the dependency scanner will either pick them up and install them, 
>> or
>> error due to missing dependencies.
> 
> Some you are saying since we do not build an actual binary that
> depends on the 64bit library we just drop the libraries we requested
> to be installed?
> 
> -M

The normal OE approach is to resolve all items by run-time dependencies.  That
is why a lot more is built then installed.

So if you want a system capable of running bash, you would create a task (and
related image) that simply has a RDEPENDS on "bash".  Everything else is
determined automatically.  So even if you build ncurses for 32-bit and 64-bit,
only the one needed by bash will be installed.

If you change this and specify that your task RDEPENDS is "bash lib64-ncurses".
 Then the system will determine the dependencies based on both bash and the
64-bit ncurses.  This will result in a system (likely 32-bit in this example)
that includes bash and lib64-ncurses and all of it's dependencies...

The point is, if you explicitly tell the system to install something it is
expected to be installed.  If you don't the automatic resolution is used to
determine install components and not everything you want may be installed.

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

Re: [yocto] RPM multilib package installation issue

[Mark Hatle]

On 9/2/11 11:24 AM, McClintock Matthew-B29882 wrote:
> On Fri, Sep 2, 2011 at 10:48 AM, Mark Hatle  wrote:
>> The normal OE approach is to resolve all items by run-time dependencies.  
>> That
>> is why a lot more is built then installed.
>>
>> So if you want a system capable of running bash, you would create a task (and
>> related image) that simply has a RDEPENDS on "bash".  Everything else is
>> determined automatically.  So even if you build ncurses for 32-bit and 
>> 64-bit,
>> only the one needed by bash will be installed.
>>
>> If you change this and specify that your task RDEPENDS is "bash 
>> lib64-ncurses".
>>  Then the system will determine the dependencies based on both bash and the
>> 64-bit ncurses.  This will result in a system (likely 32-bit in this example)
>> that includes bash and lib64-ncurses and all of it's dependencies...
>>
>> The point is, if you explicitly tell the system to install something it is
>> expected to be installed.  If you don't the automatic resolution is used to
>> determine install components and not everything you want may be installed.
> 
> One would expect then if I did a:
> 
> MULTILIB_IMAGE_INSTALL += "lib64-perl"
> 
> I would be a 64bit perl and a slew of 64 bit libraries installed. I'm
> still trying to figure out why this is not happening on my particular
> build.

For everything I see, that should work.

In classes/image.bbclass, RDEPENDS is augmented by the contents of
IMAGE_INSTALL, LINGUAS_INSTALL, MULTILIB_IMAGE_INSTALL, and 
NORMAL_FEATURE_INSTALL.

The place to start looking for this is within the log.do_rootfs in the rootfs
directory you are working on.  You should see something that indicates it's
trying to install the "lib64-perl".  (in the case of RPM, it should eventually
rename it to "perl" -- but choose the 64-bit version.)

--Mark

> -M

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

Re: [yocto] RPM multilib package installation issue

[Mark Hatle]

On 9/2/11 1:36 PM, McClintock Matthew-B29882 wrote:
> On Fri, Sep 2, 2011 at 12:09 PM, Mark Hatle  wrote:
>> For everything I see, that should work.
>>
>> In classes/image.bbclass, RDEPENDS is augmented by the contents of
>> IMAGE_INSTALL, LINGUAS_INSTALL, MULTILIB_IMAGE_INSTALL, and 
>> NORMAL_FEATURE_INSTALL.
> 
> The bitbake side is fine, It's getting put into RDEPENDS and all the
> packages are beinh built properly. RPMs are built as well.
> 
>> The place to start looking for this is within the log.do_rootfs in the rootfs
>> directory you are working on.  You should see something that indicates it's
>> trying to install the "lib64-perl".  (in the case of RPM, it should 
>> eventually
>> rename it to "perl" -- but choose the 64-bit version.)
> 
> However, I don't see code that invokes package_rpm.bbclass properly.
> It looks like it could work, but no where is MLPREFIX set for image.
> There is some override or something missing on my end or in the code
> to properly export these vars for the ML rpm install scenario.
> 
> Further more, from what I see no where in rootfs_rpm.bbclass do we
> pass MULTILIB_PACKAGE_INSTALL into the list of packages to be
> installed... thus they fall off. ipk looks like it might have this
> stuff done.

This looks like a typo of some sorts:

image.bbclass:RDEPENDS += "${IMAGE_INSTALL} ${LINGUAS_INSTALL}
${MULTILIB_IMAGE_INSTALL} ${NORMAL_FEATURE_INSTALL}"

image.bbclass:export MULTILIB_PACKAGE_INSTALL ?= "${MULTILIB_IMAGE_INSTALL}"

So you should be setting MULTILIB_IMAGE_INSTALL, this should feed into the
RDEPENDS and that should in turn seed the roofs stuff..  So there looks to be a
disconnect of some sort between the implementation of the image.bbclass and the
individual package_*.bbclasses.

(The only place I see MULTILIB_PACKAGE_INSTALL is in rootfs_ipk.bbclass.)

The way the rootfs_rpm (which uses package_rpm) gets the list of things to
install is via:

package_linguas=INSTALL_PACKAGES_LINGUAS_RPM=LINGUAS_INSTALL

package_to_install=INSTALL_PACKAGES_NORMAL_RPM=PACKAGE_INSTALL="${IMAGE_INSTALL}
 ${FEATURE_INSTALL}"

package_attemptonly=INSTALL_PACKAGES_ATTEMPTONLY_RPM=PACKAGE_INSTALL_ATTEMPTONLY=FEATURE_INSTALL_OPTIONAL

Where you see RPM above, replace with ipk and deb and the same ordering should
be used.  So based on that, RDEPENDS is being populated from the
"image.bbclass", but nothing is populating the MULTILIB_IMAGE_INSTALL like it
should be.  Either it needs to be added to the 'PACKAGE_INSTALL' or something
similar needs to be invented and added to each of the rootfs_* types.  (Note,
there needs to be a translation step between the definition of
MULTILIB_IMAGE_INSTALL and where it's used.. since things like "zlib" can become
"libz1" via name translation.  (translation happens in runtime_mapping_rename if
I remember correctly.. in image.bbclass)

I'd suggest you file a bug about this in the yocto system.  We'll get someone to
work on it...  (I agree it's broken BTW..)  The ipk usage may turn out to be an
example for the deb and rpm usage... but the three should continue to be in sync
for most of it.

--Mark

> -M
> 
> -M

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

Re: [yocto] [PATCH 0/2] More fixes for bug 1428

[Mark Hatle]

On 9/9/11 2:13 PM, Tom Zanussi wrote:
> On Fri, 2011-09-09 at 10:45 -0700, Richard Purdie wrote:
>> On Fri, 2011-09-09 at 08:57 -0500, Tom Zanussi wrote:
>>> On Fri, 2011-09-09 at 06:17 -0700, Richard Purdie wrote:
 On Thu, 2011-09-08 at 14:27 -0500, tom.zanu...@intel.com wrote:
> From: Tom Zanussi 
>
> oe-core commit dc3a8274c7e935fa564eea142d2535c9bcf2b272 for YOCTO #1428
> broke meta-intel x86_64 builds:
>
> NOTE: Resolving any missing task queue dependencies
> ERROR: Nothing RPROVIDES 'initramfs-live-install' (but 
> /usr/local/src/yocto/sugarbay/meta/recipes-core/images/core-image-minimal-initramfs.bb
>  RDEPENDS on or otherwise requires it)
> ERROR: initramfs-live-install was skipped: incompatible with host 
> x86_64-poky-linux
>
> This patchset restores the build.
>
> Build and install-tested on sugarbay and crownbay.
>
> More fixes for [YOCTO #1428]
>
> The following changes since commit 
> b86f811663d834064af1e6778c408eb904fad0b9:
>   Darren Hart (1):
> n450: update linux-yocto PREFERRED_VERSION to 3.0%
>
> are available in the git repository at:
>
>   git://git.yoctoproject.org/meta-intel.git tzanussi/1428-fix
>   
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/log/?h=tzanussi/1428-fix
>
> Tom Zanussi (2):
>   meta-intel/common: create a grub2 version initramfs-live-install
>   meta-intel/common: remove initramfs-live-install 1.0 bbappend

 Is there a disadvantage to moving to grub2 in OE-Core and then bringing
 these pieces into sync?

>>>
>>> Yes, it would make sense - the plan was to do that during the 1.2
>>> cycle...
>>
>> If someone can confirm that 32 and 64 bit live images work with grub2
>> and there is no good reason not to do this, I'd be in favour of doing
>> this now rather than explain why its a mess...
>>
> 
> I haven't tried the 32-bit BSPs with grub2 - been focused on other
> things until this incomplete fix for 1428 seems to have forced the
> issue, but can try it over the weekend and see what happens.
> 
> grub2 isn't a simple version bump from the legacy grub 0.97, but is a
> completely incompatible re-write - I thought being more cautious in
> removing the grub 0.97 that's worked fine for everything but the couple
> of 64-bit meta-intel BSPs that need it would be something for 1.2, but
> if it can go in now, why not...

We need to keep the older grub 0.97 as well.  grub2 is GPLv3 and a lot of people
will refuse to use it based on that.

--Mark

> Tom
> 
>> Cheers,
>>
>> Richard
>>
> 
> 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

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

Re: [yocto] tcf-agent fail to run on imx28evk

[Mark Hatle]

On 9/15/11 8:43 AM, Cui, Dexuan wrote:
> Can you please try to remove “image-prelink" from conf/local.conf’s 
> USER_CLASSES
> and re-build an image to see if that would make a difference?
> 
>  
> 
> Recently looks prelinking was broken and this causes segfaults in some 
> packages.
> 

I believe the latest prelinker update went in this morning (US time).  So try
again and see if that resolves the issue.

To check if you are running the latest version of the prelinker,
meta/recipes-devtools/prelink/prelink_git.bb should reference the SRCREV of
3e3f9b0876aa5ac83a783a95b8bab52cb38ed785

There was a printf issue that was causing things using threading, specifically
thread local storage, to not always prelink properly.  ARM seemed to have
components that were randomly affected.

--Mark

> 
> Thanks,
> 
> -- Dexuan
> 
>  
> 
> *From:*yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org]
> *On Behalf Of *蔡振军
> *Sent:* Thursday, September 15, 2011 5:27 PM
> *To:* yocto@yoctoproject.org
> *Subject:* [yocto] tcf-agent fail to run on imx28evk
> 
>  
> 
> Hi ALL,
> 
>  I build one image for imx28evk. But tcf-agent fail to start in boot
> process and get same fault when I run it manually.
> 
> Log like this:
> 
> /INIT: Entering runlevel: 5/
> 
> /Starting syslogd/klogd: done/
> 
> /Starting tcf-agent: Alignment trap: tcf-agent (1526) PC=0x4e704ca4
> Instr=0xe7913103 Address=0xfffe FSR 0x001/
> 
> /Segmentation fault/
> 
> /FAIL/
> 
> /Stopping Bootlog daemon: bootlogd./
> 
>  I have tried to update the version of tcf-agent. Error still exist.
> 
>  
> 
> Best regards
> 
> Feye
> 
>  
> 
>  
> 
> 蔡振军
> 
> 网新技术有限公司物联网事业部
> 
> 杭州天目山路226号网新大厦
> 
> 电话-138 6745 1910
> 
>  
> 
> 
> 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

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

Re: [yocto] about symbol link of library

[Mark Hatle]

On 10/13/11 4:37 AM, Ni Qingliang wrote:
> hello all.
> 
> I have added 2 packages, one is lib, and the other is bin.
> 
> the lib will generate 2 files:
>   libx.so.1.0.1
>   libx.so -> libx.so.1.0.1
> the latter linked to the other one.
> 
> the bin package will link to the libx.so.
> 
> compile/install are all OK, but when populate rootfs, I got error:
> error: Failed dependencies:
> | libx.so is needed by bin..

I suspect your libx.so.1.0.1 is missing an SONAME.  One should be added to it
that matches the filename of the "real" library.  (It's possible that it has an
soname already, it just doesn't match the filename.)

Once that is done, then the dynamic linker should be able to find it w/o the
libx.so link.

(The links should only ever be used for development.  This is a somewhat common
bug, and a good way to find these problems.)

I'd also suggest we add a sanity check for this condition, so it will be easier
for people to identify in the future.

--Mark

> after checked the rpm, the libx.so is located in libx-dev, but not in
> libx.
> 
> what is the right way to resolve this problem?
> 
> 
> 
> 

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

Re: [yocto] Proposed roadmap and design for Hob improvement

[Mark Hatle]

On 10/25/11 11:08 AM, McClintock Matthew-B29882 wrote:
> On Sun, Oct 23, 2011 at 10:12 PM, Yu, Ke  wrote:
>>> Seems like with the build packages and build image steps separated you could
>>> skip the build step completly for most packages if we ship or host 
>>> pre-built build
>>> packages
>>>
>>> -M
>>
>> Yes, current design supports this scenario, i.e. if some packages are 
>> already pre-built, HOB will notice that and won't build them again.
> 
> It would be nice to be able to skip the package generation if the RPM
> already exists somewhere. This could provide significant speedup above
> what is already provided by sstate-cache. Although other issues might
> need to be solved

sstate-cache already caches the results of the package builds (not just RPM).
This is needed to be able to populate both the sysroot and the package set for
the image generation step.

To me what is a bigger deal is to break up the image generation into an external
step.. so I can simply start with a set of packages and build them.  (since
sysroots and similar are not needed in this situation.)

--Mark

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

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

[yocto] prelink-cross project sync update

[Mark Hatle]

(I'm going to try to send out these quick blurbs as prelink-cross is synced to
the upstream.  Upstream changes are fairly infrequent, so this will be a low
volume set of emails.  Most emails in the future will be shorted then this one.)

prelink-cross has been synced up to the latest upstream prelink changes.

The latest changes include:

2011-10-12  Jakub Jelinek  

* src/main.c (layout_page_size): New variable.
(OPT_LAYOUT_PAGE_SIZE): Define.
(options): Add --layout-page-size option.
(set_default_layout_page_size): New function in i?86/x86_64
resp. empty macro on other architectures.
(main): Call it.
* src/arch-i386.c (i386_layout_libs_init): Fail if
l->max_page_size is larger than 2MB and exec_shield is true.
Compute reg0s as REG0S rounded up to l->max_page_size
boundary and use it instead of REG0S.
(i386_layout_libs_pre): Compute reg0s as REG0S rounded up to
l->max_page_size boundary and use it instead of REG0S.
Fix up a pasto in computation of virt parameter for
third i386_find_free_addr call.
* src/prelink.h (layout_page_size): New decl.
* src/layout.c (layout_libs): Set max_page_size and
l.max_page_size to maximum of plarch->max_page_size
and layout_page_size.  Fail if mmap_base or mmap_end
aren't max_page_size aligned.
* src/arch-ppc.c (ppc_layout_libs_pre): Give up if
l->max_page_size is larger than 64KB.

In essence what this does is adds a new option "--layout-page-size" that allows
someone to override the "max_page_size" value when necessary.  (It's not a true
override as the max_page_size is set to either the existing value or
layout-page-size whichever is larger.)

The upstream change also added dynamic run-time detection for the AMD Bulldozer
platform, setting the default to 32k.  Since run-time detection is contrary to
the existing prelink-cross usage, the code has been disabled.

As usual, the upstream version is in the "master" branch, and the cross version
is in the "cross_prelink" branch.

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

Re: [yocto] building and using yocto 1.1

[Mark Hatle]

What machine are you using (amount of ram, disk space, and cpu cores)?

What configuration did you set for parallel builds?

I can build 1.1 on an 8 core i7 system w/ 8 GB of ram, set with parallel
settings of 8 thread and 8 parallel make jobs, in about 100 minutes (or less).

--Mark

On 10/28/11 9:20 AM, Xianghua Xiao wrote:
> when I built 1.0 out of the box, it took 7 hours.
> on the same machine/network, yocto 1.1 took a full 12 hours, not sure
> what happened to cause this nearly doubled build time.
> 
> after the default build(bitbake core-image-sato), I run 'runqemu
> qemux86', click on 'tasks', try to add a new task, however my input is
> shown non-english, or garbage on screen, which I have seen the same
> issue on yocto1.0 release as well. this is a 10.04 ubuntu 64bit
> machine.
> 
> don't know what to say about it, just my OOB(out-of-box) experience
> 
> xianghua
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

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

Re: [yocto] building and using yocto 1.1

[Mark Hatle]

On 10/28/11 11:13 AM, Xianghua Xiao wrote:
> core2duo E7200 2.53Ghz  4GB 500GB
> 
> 1 thread 1 parallel due to past experience I had from the
> past(parallel make did not work well reliably)

It is a goal of the Yocto Project (and Open Embedded) that parallel building is
full supported, and any identified bugs are fixed quickly.

Enable parallel builds and your performance will be significantly better.

If you have hyperthreading enabled, and setup a 4/4 parallel build.  I would
expect about a 4-5 hour build time.  (May be faster)

--Mark

> thanks,
> xianghua
> 
> 
> On Fri, Oct 28, 2011 at 9:45 AM, Mark Hatle  wrote:
>> What machine are you using (amount of ram, disk space, and cpu cores)?
>>
>> What configuration did you set for parallel builds?
>>
>> I can build 1.1 on an 8 core i7 system w/ 8 GB of ram, set with parallel
>> settings of 8 thread and 8 parallel make jobs, in about 100 minutes (or 
>> less).
>>
>> --Mark
>>
>> On 10/28/11 9:20 AM, Xianghua Xiao wrote:
>>> when I built 1.0 out of the box, it took 7 hours.
>>> on the same machine/network, yocto 1.1 took a full 12 hours, not sure
>>> what happened to cause this nearly doubled build time.
>>>
>>> after the default build(bitbake core-image-sato), I run 'runqemu
>>> qemux86', click on 'tasks', try to add a new task, however my input is
>>> shown non-english, or garbage on screen, which I have seen the same
>>> issue on yocto1.0 release as well. this is a 10.04 ubuntu 64bit
>>> machine.
>>>
>>> don't know what to say about it, just my OOB(out-of-box) experience
>>>
>>> xianghua
>>> ___
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>

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

Re: [yocto] root paths in packages

[Mark Hatle]

On 10/31/11 5:57 AM, Mike Tsukerman wrote:
> Hello,
> 
> I've build rpm packages and met some interesting things. 
> In the rpm all scripts and files include root paths from machine that i've 
> build on.
> how can i change that?

Examples of the problem are definitely needed.  There are some cases where
embedded paths simply refer to the place on the disk a source file or similar
came from during the build.  Depending on where these references are, they may
be considered safe and acceptable.  However, in most places something like this
would be considered an error.

--Mark

> -- 
> Best regards, Mike Tsukerman
> 
> jabber: miketsuker...@gmail.com 
> jabber: war...@jabnet.org 
> skype: w_a_r_z_o_n
> 
> 
> 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

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

Re: [yocto] what's the proper value for BB_NUMBER_THREADS?

[Mark Hatle]

On 10/30/11 11:15 AM, Robert P. J. Day wrote:
> On Sun, 30 Oct 2011, Christian Gagneraud wrote:
> 
>> On 30/10/11 15:32, Robert P. J. Day wrote:
>>>
>>>all the docs recommend twice the number of cores (AFAICT), yet the
>>> template local.conf file suggests that, for a quad core, the value of
>>> 4 would be appropriate.  shouldn't that say 8?  same with
>>> PARALLEL_MAKE?
>>
>> Hi Robert,
>>
>> The Poky ref manual says (rule of thumb) x2 for BB_NUMBER_THREADS,
>> and x1.5 for PARALLEL_MAKE.
> 
>   if that's the case, anyone object to my submitting a patch to
> update local.conf.sample appropriately?
> 
> rday
> 

I agree the manual and local.conf files should match.  The issue seems to be
that the perfect values are subjective.  Things like memory, disk speed, chipset
latency, and of course processor speed/cores all affect the optimal setting.
But we do need a consistent rule of thumb..  I myself usually use x2 for both
THREADS and MAKE.

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

[yocto] Announcement: pseudo 1.2 released

[Mark Hatle]

Making a release announcement on behalf of the pseudo maintainer...

pseudo 1.2 is now released.  It can be pulled from:

Via git:

git://github.com/wrpseudo/pseudo.git
git://git.yoctoproject.org/pseudo.git

branch PSEUDO_1_2

or the tarball from

http://downloads.yoctoproject.org/releases/pseudo/pseudo-1.2.tar.bz2

The included ChangeLog.txt
(http://git.yoctoproject.org/cgit/cgit.cgi/pseudo/tree/ChangeLog.txt?h=PSEUDO_1_2)

Contains a full list of changes.

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

Re: [yocto] libtool can't read a la files

[Mark Hatle]

On 11/3/11 4:50 AM, Mike Tsukerman wrote:
> Hello, I've build core-image-minimal-dev (it does not metter for what
> architecture, the same bugs appears in arm and i586) image and faced a 
> problem.
> When i'm trying to build something from tarball, i get a libtool errors. It's
> not only for libz and not every time happens. What is going wrong?
> But all .la files exists.
> 
> libtool: link: (cd ".libs" && rm -f "librpmbuild.so.2" && ln -s
> "librpmbuild.so.2.0.1" "librpmbuild.so.2")
> libtool: link: (cd ".libs" && rm -f "librpmbuild.so" && ln -s
> "librpmbuild.so.2.0.1" "librpmbuild.so")
> /bin/sed: can't read =/usr/lib/libz.la <http://libz.la>: No such file or 
> directory
> libtool: link: `=/usr/lib/libz.la <http://libz.la>' is not a valid libtool 
> archive
> make[2]: *** [librpmbuild.la <http://librpmbuild.la>] Error 1
> make[2]: Leaving directory `/home/root/rpm-4.9.1.2/build'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/root/rpm-4.9.1.2'
> make: *** [all] Error 2

rpm 4.9.1.2 is not part of Yocto.  So this might be part of the issue.  RPM 4
historically has had significant issues with cross compiling.  (We use RPM 5
within Yocto for this reason.)

The Link syntax of "=/usr/lib/libz.la" means link the library located within the
sysroot directory.

The version of rpm(4) which you are attempting to compile does not understand
this syntax.  Either the issue is located within the libtool command itself, or
within one of the makefile fragments.

The version of libtool shipped with Yocto understands the "=" syntax.  Did you
use it, either by running libtoolize --copy --force --or-- using the built-in
autotools recipe helper?

-Mark

> 
> On Thu, Nov 3, 2011 at 8:49 AM,  <mailto:yocto-requ...@yoctoproject.org>> wrote:
> 
> Send yocto mailing list submissions to
>yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>https://lists.yoctoproject.org/listinfo/yocto
> or, via email, send a message with subject or body 'help' to
>yocto-requ...@yoctoproject.org 
> <mailto:yocto-requ...@yoctoproject.org>
> 
> You can reach the person managing the list at
>yocto-ow...@yoctoproject.org <mailto:yocto-ow...@yoctoproject.org>
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of yocto digest..."
> 
> 
> Today's Topics:
> 
>   1. Announcement: pseudo 1.2 released (Mark Hatle)
>   2. Re: Build error while following Appendix A. Yocto Project
>  Development manual (Jim Abernathy)
>   3. Help diagnosing a build failure involving ncurses, gettext,
>  and eglibc (Darren Hart)
>   4. [PATCH 0/1] Development Manual Appendix A changes
>      (tom.zanu...@intel.com <mailto:tom.zanu...@intel.com>)
>   5. [PATCH 1/1] documentation/dev-manual: BSP Development Example
>  changes (tom.zanu...@intel.com <mailto:tom.zanu...@intel.com>)
> 
> 
> --
> 
> Message: 1
> Date: Wed, 2 Nov 2011 15:49:10 -0500
> From: Mark Hatle  <mailto:mark.ha...@windriver.com>>
> To: Yocto Project mailto:yocto@yoctoproject.org>>
> Cc: "Seebach, Peter"  <mailto:peter.seeb...@windriver.com>>
> Subject: [yocto] Announcement: pseudo 1.2 released
> Message-ID: <4eb1acc6.8040...@windriver.com
> <mailto:4eb1acc6.8040...@windriver.com>>
> Content-Type: text/plain; charset="ISO-8859-1"
> 
> Making a release announcement on behalf of the pseudo maintainer...
> 
> pseudo 1.2 is now released.  It can be pulled from:
> 
> Via git:
> 
> git://github.com/wrpseudo/pseudo.git 
> <http://github.com/wrpseudo/pseudo.git>
> git://git.yoctoproject.org/pseudo.git 
> <http://git.yoctoproject.org/pseudo.git>
> 
> branch PSEUDO_1_2
> 
> or the tarball from
> 
> http://downloads.yoctoproject.org/releases/pseudo/pseudo-1.2.tar.bz2
> 
> The included ChangeLog.txt
> 
> (http://git.yoctoproject.org/cgit/cgit.cgi/pseudo/tree/ChangeLog.txt?h=PSEUDO_1_2)
> 
> Contains a full list of changes.
> 
> --Mark
> 
> 
> --
> 
> Message: 2
> Date: Wed, 02 Nov 2011 18:05:05 -0400
> From: Jim Abernathy mailto:jfaberna...@gmail.com>>
> To: To

Re: [yocto] do all recipes really need LIC_FILES_CHKSUM?

[Mark Hatle]

On 11/7/11 10:01 AM, Robert P. J. Day wrote:
> 
>   current poky ref manual seems pretty adamant about need for
> LIC_FILES_CHKSUM:
> 
> "Note that this variable is mandatory for all recipes, unless the
> LICENSE variable is set to "CLOSED".
> 
> but there's at least one counter-example,
> meta-demoapps/recipes-graphics/pong-clock/pong-clock_1.0.bb:

Bug in the example.. it should be fixed.

--Mark

> =
> 
> DESCRIPTION = "A clock combined with a game of pong"
> LICENSE = "GPLv2+"
> DEPENDS = "virtual/libx11 xdmcp xau"
> 
> SRC_URI = "file://pong-clock-no-flicker.c"
> 
> S = "${WORKDIR}"
> 
> do_compile () {
> ${CC} -o pong-clock pong-clock-no-flicker.c `pkg-config --cflags 
> --libs x11 xau xdmcp`
> }
> 
> do_install () {
> install -d ${D}${bindir}
> install -m 0755 pong-clock ${D}${bindir}
> }
> 
> =
> 
> so what's the story here?
> 
> rday
> 

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

Re: [yocto] do all recipes really need LIC_FILES_CHKSUM?

[Mark Hatle]

On 11/7/11 10:24 AM, Robert P. J. Day wrote:
> On Mon, 7 Nov 2011, Mark Hatle wrote:
> 
>> On 11/7/11 10:01 AM, Robert P. J. Day wrote:
>>>
>>>   current poky ref manual seems pretty adamant about need for
>>> LIC_FILES_CHKSUM:
>>>
>>> "Note that this variable is mandatory for all recipes, unless the
>>> LICENSE variable is set to "CLOSED".
>>>
>>> but there's at least one counter-example,
>>> meta-demoapps/recipes-graphics/pong-clock/pong-clock_1.0.bb:
>>
>> Bug in the example.. it should be fixed.

I'm not surprised that meta-demoapps is missing this stuff..  AFAIK the stuff
here isn't run though the normal build/QA process.

If this information isn't deprecated as Gary thought it might be... then it
absolutely should be fixed.

>   okay, but it's really not hard to find more examples like that,
> such as meta-demoapps/recipes-graphics/libxklavier/libxklavier_3.9.bb:
> 
> DESCRIPTION = "Utility library to make using XKB easier"
> SECTION = "x11/libs"
> DEPENDS = "iso-codes libxml2 glib-2.0 libxkbfile"
> LICENSE = "LGPL"
> PR = "r2"
> 
> SRC_URI = "${SOURCEFORGE_MIRROR}/gswitchit/libxklavier-${PV}.tar.bz2 \
>file://pkgconfigfix.patch;patch=1"
> 
> inherit autotools
> 
>   or "xournal" in the same directory, etc, etc.  i'm not trying to be
> annoyingly pedantic (he lied), just pointing out the inconsistencies.
> 
> rday
> 

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

[yocto] Mailing list etiquette question...

[Mark Hatle]

I was wondering if this or any other Yocto controlled mailing list allows job
postings?

I don't see anything forbidding it at this point -- but I'm not sure I want to
start a trend unless there is some consensus.

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

Re: [yocto] rpm dependency errors

[Mark Hatle]

On 11/14/11 10:16 PM, Michael E Brown wrote:
> I've now run across this same error in two different contexts, and am
> having difficulty trying to figure out what is going on
> 
> First, while building meta-toolchain-sdk, I ran into
> http://pastebin.com/BT02UYk1
>  ... cut ...
> Processing task-core-standalone-gmae-sdk-target-dbg...
> | error: Failed dependencies:
> |   libgthread-2.0.so.0 is needed by libgupnp-1.0-3-0.16.1-r0.sh4
> |   libresolv.so.2 is needed by libgupnp-1.0-3-0.16.1-r0.sh4
> 
> I've confirmed that the libgupnp rpm has only SH4 binaries in it.
> 
> Next, while building a custom image, I ran across the same error with
> portmap and tcp-wrappers:
> 
> http://pastebin.com/dRb5Dum8
> 
> Note in the pastebin I extracted tcp-wrappers and 'file' says that
> everything is SH4.

This type of error usually means that those two items were required as libraries
(for the target packages) and no rpm packages available provide those items.

Usually it means they were not being packaged, but did end up in the sysroot
somehow.

The items in the pastebin are a different issue, I suspect... From the pastebin:

(Lets start with the requirements first)
> $ rpm -qp --requires tcp-wrappers-7.6-r0.sh4.rpm
> warning: tcp-wrappers-7.6-r0.sh4.rpm: Header V4 DSA signature: NOKEY, key ID
fe659c6d
> libc6 >= 2.13

This is a package requirement..

> libwrap0 >= 7.6

As is this one..

> rtld(GNU_HASH)

This is a virtual requirement -- I need a rtld that supports GNU_HASH.

> libc.so.6
> libc.so.6(GLIBC_2.3)
> libc.so.6(GLIBC_2.2)

Above three are library SONAME requirements.  I first require something with the
SONAME of "libc.so.6", and then also require two versioned symbols GLIBC_2.3 and
GLIBC_2.2.

> libwrap.so.0

This is simply an SONAME requirement.

> $ rpm -qp --provides libc6-2.13-r15+svnr14157.sh4.rpm
> warning: libc6-2.13-r15+svnr14157.sh4.rpm: Header V4 DSA signature: NOKEY, 
> key ID 47031d66
> rtld(GNU_HASH)  
> glibc  
> libc6 = 2.13-r15+svnr14157

When you look at the provides, we're not providing any of the soname/shared
library requirements.   There are a few possibilities as to the cause:

*) You simply didn't package the libraries..  check with rpm -qp -l .
Do you see /lib/libc.so.6 there?

*) The libraries inside of this package are invalid for some reason?

*) objdump isn't able to read the soname values from these libraries for some
reason.

*) elfutils version of objdump isn't able to read the soname values from these
libraries for some reason.

... look into each of those and see if you can figure out what might be wrong.
If you get to the point of investigating objdump or elfutils-objdump -- be sure
to run it against the versions from the package and not the work directory.  (It
is possible something is getting mangled at package time.)

--Mark

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

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

Re: [yocto] rpm dependency errors

[Mark Hatle]

On 11/15/11 9:06 PM, Michael E Brown wrote:

On Mon, 2011-11-14 at 22:16 -0600, Michael E Brown wrote:

I've now run across this same error in two different contexts, and am
having difficulty trying to figure out what is going on

First, while building meta-toolchain-sdk, I ran into
http://pastebin.com/BT02UYk1
  ... cut ...
Processing task-core-standalone-gmae-sdk-target-dbg...
| error: Failed dependencies:
|   libgthread-2.0.so.0 is needed by libgupnp-1.0-3-0.16.1-r0.sh4
|   libresolv.so.2 is needed by libgupnp-1.0-3-0.16.1-r0.sh4

I've confirmed that the libgupnp rpm has only SH4 binaries in it.

Next, while building a custom image, I ran across the same error with
portmap and tcp-wrappers:

http://pastebin.com/dRb5Dum8

Note in the pastebin I extracted tcp-wrappers and 'file' says that
everything is SH4.


As a bit more information, I found that when I changed to "package_ipk"
vs rpm in my local.conf, I was able to do image build and sdk builds
without incident. So this problem looks like something specific to rpm
package builds. Is there any solution to this other than just not using
rpm?


RPM packages contain more dependency information then ipk and deb packages. 
This is not a bug, but a feature.  When using RPM packages not only are 
specified dependencies there, but also soname and file level dependencies.


There is an outstanding item to add these soname and file level dependencies to 
the OE/Yocto deb and ipk implementations as well.


Trust me, if the dependency is failing, then there is something wrong with the 
packages or the binaries within the packages (or they're not compatible with the 
elfutils mechanisms used to dump that information.)


You really do need to understand the actual files present in the packages, and 
if they have the corresponding sonames that the dependent packages are looking for.


If you post your layer somewhere, I can attempt to reproduce the problem.

--Mark


--
Michael

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


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

Re: [yocto] /usr/bin/env dependencies

[Mark Hatle]

On 11/15/11 10:19 PM, Mike Tsukerman wrote:

Hello,

I'm trying to build my own image for my own machine configuration ( based on
beagleboard )
and get some errors. Please tell me what package is missing?

error: Failed dependencies:
| /usr/bin/env is needed by automake-1.11.1-r4.armv7ahf
| /usr/bin/env is needed by slang-2.2.4-r6.armv7ahf
| /usr/bin/env is needed by mc-4.7.5.2-r2.armv7ahf
| /usr/bin/env is needed by autoconf-2.68-r3.armv7ahf
| /usr/bin/env is needed by intltool-0.40.6-r5.armv7ahf
| /usr/bin/env is needed by python-core-2.7.2-r0.0.armv7ahf
| /usr/bin/env is needed by gnu-config-0.1+cvs20080123-r4.armv7ahf


Each of those packages contains a shell script that is invoked with:

#!/usr/bin/env ...

Likely the "..." bit is python.

Usually busybox or coreutils will provide the /usr/bin/env binary.

If your configuration has flattened the directory structure and removed "/usr", 
then each of those packages have flaws in them and are not respecting the 
revised "bindir" information -- otherwise you are simply missing functionality 
in either busybox or coreutils.


--Mark


--
Best regards, Mike Tsukerman

jabber: miketsuker...@gmail.com 
jabber: war...@jabnet.org 
skype: w_a_r_z_o_n



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


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

Re: [yocto] applying the Yocto Project to Automotive interests

[Mark Hatle]

On 11/14/11 3:49 PM, Erway, Tracey M wrote:

Folks,

I’m presenting a Yocto Project session at the upcoming Linux Foundation
Automotive Summit in Yokohama, Japan at the end of November.

I thought that folks on this list might have suggestions for pertinent subject
matter that I should include in the session.

It’s only 30 minutes, so I’ll need to paint a broad picture.

All suggestions welcome,


Automotive release cycles are -very- long.. in the 4-5 year development time 
frame and 10-15 year product support time frame.  As I understand it, the Yocto 
Project does not intend to continue support for any release within those time 
frames.  This is where the end user and/or OSV will need to determine the 
support requirements and support policies outside of what Yocto provides.


Yocto does not provide an "application framework" (this was a big selling point 
of Moblin/MeeGo).  Yocto allows someone to generate their own Linux distribution 
for their own needs.  What this means to someone like GENIVI is that they CAN 
create an application framework based on Yocto, but it would be work they would 
need to do (with us) likely in using a custom layer that specifies specific 
distribution settings, enhancements, etc.


Yocto is a cross-compiled build environment.  This is a departure to a lot of 
the Moblin/MeeGo work that has occurred in the past.  The advantages are you can 
use any commodity PC to target any (supported) architecture.  Disadvantages are 
that when you introduce new code, you need to ensure that it has a recipe (build 
instructions for bitbake) and can cross compile.  If everyone has to do the same 
work over and over, this can be time consuming and counter productive.  If 
people work together, the time and support burden are dramatically reduced. 
This can help negate issues people have had in the past with cross compiling. 
Note: Yocto -does- have a self hosted compile environment if it is needed, this 
is usually when cross compiling isn't easy to do for some reason.


Yocto currently does not support a set of "blessed" binary packages.  Our 
expectation is that the users of Yocto will create their own distributions, and 
then in turn provide binary packages to their own customers/users in whatever 
mechanism is appropriate.  If the automotive folks want to start with binary 
packages and simply add their own stuff on top, someone will need to create the 
distribution (see above about settings and frameworks) and provide the "blessed" 
package feeds.


Anyone have any other questions/comments let me know.  I'm pretty familiar with 
automotive and GENIVI requirements as of a few years ago.  I'm a bit out of date 
with the current work however.


--Mark


/t

*/Tracey M. Erway/*

*/The Yocto Project* - /**/www.yoctoproject.org/*

Intel Corporation

503 . 264 . 6435 Effective VM to Email Service

503 . 709 . 1221 Cell / Blackberry



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


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

Re: [yocto] Yocto usability questions

[Mark Hatle]

On 11/16/11 4:07 PM, Jeff Osier-Mixon wrote:

Mark Hatle said:

Yocto is a cross-compiled build environment. This is a departure to a lot of
the Moblin/MeeGo work that has occurred in the past. The advantages are you
can use any commodity PC to target any (supported) architecture.
Disadvantages are that when you introduce new code, you need to ensure that
it has a recipe (build instructions for bitbake) and can cross compile. If
everyone has to do the same work over and over, this can be time consuming
and counter productive. If people work together, the time and support burden
are dramatically reduced. This can help negate issues people have had in the
past with cross compiling. Note: Yocto -does- have a self hosted compile
environment if it is needed, this is usually when cross compiling isn't easy
to do for some reason.


Mark & everyone else listening:

Would you say that (1) the need for a recipe and (2) the requirement to
cross-compile are two of the most major usability or learning-curve
disadvantages of working with the Yocto Project (and oe-core)? What would be a
third disadvantage from a usability standpoint?


1) Recipe isn't needed, unless you want automatically reproduced builds and to 
share the instructions with others... which is one our our goals.


I don't see the recipe as anything different then an SRPM, Debian src.tgz, etc. 
 The only obstacle is that it's "different" that what desktop distributions do.


2) I think cross compilation is by far the largest obstacle.  People not 
familiar with the GNU auto tools, cross compiling in general, or simply 
inexperienced developers seem to have a lot of problems with this.  I think 
OE/Yocto does a good job at providing GNU auto tools and make helpers, but it's 
far from perfect.  As far as how to improve it...  we need to keep incrementally 
improving our support, documentations and examples.  We also need to foster a 
community where people share the work they've already done... thus eliminating 
this issue.  (The meta-oe layer is a good place for this already.)


I'm sure there are other usability issues, but I've been doing cross compilation 
for so long that I'm a bit blind to some of the issues.


To me the biggest thing we need to do is make sure someone who is familiar with 
desktop Linux can step in and apply what they know to building a recipe and 
fixing cross compilation problems.  If we can do that -- it will go a long way 
toward helping resolve the issues that cause people to do self-hosted 
compilation on slow target systems.  (Note there are some things that are simply 
complicated and difficult to do like Firefox.. for those the only answer is to 
have "experts" do the work and make it available to the novices so they can see 
and understand how to work around various issues.)



Another way to put it: if you could change three things about the Yocto Project
to make it more approachable for someone who has never used it before, what
would they be?


To re-iterate:

*) We need a resource for contributed packages (meta-oe?) that will eliminate 
most of the problem.


*) We need good examples of problems and solutions to cross compilation 
difficulties

*) We need to continue to identify "common" issues and work to resolve them in 
the tooling we already support


--Mark


--
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel http://yoctoproject.org
<http://yoctoproject.org/>



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


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

Re: [yocto] Adding line to ld.so.conf

[Mark Hatle]

On 11/21/11 10:17 AM, Marc Ferland wrote:

On Mon, Nov 21, 2011 at 11:04 AM, Khem Raj mailto:raj.k...@gmail.com>> wrote:

On Mon, Nov 21, 2011 at 7:35 AM, Marc Ferland mailto:marc.ferl...@gmail.com>> wrote:
 > Hi,
 >
 > What's the proper way to add a line to the ld.so.conf file for a new 
library
 > I am adding?
 >

if the libraries is in standard paths you dont have to add it but if
its in a special path
then just add the absolute path to the library e.g. /opt/lib if your
library is in /opt/lib
and then run ldconfig


What I meant was how to do it in a recipe file. I don't want to modify
ld.so.conf and run ldconfig each time I create a new image.


There are issues with playing with ld.so.conf when doing a cross image 
generation.  ldconfig doesn't always work during the rootfs process, most people 
don't notice since it's simply not necessary to be run in most cases!


Lets assume for a minute that it does work in all cases.. (I'll explain a better 
solution in a bit.)


You would want a post install script that:

checks to see if the ld.so.conf already contains the line you need, if it does 
NOT, you would then add the line to the ld.so.conf file.  Then you would run 
ldconfig within the post install script -- if you are not doing a cross install. 
 (Cross installs automatically attempt to run ldconfig.)


Something like...

grep -q /opt/lib ${D}/etc/ld.so.conf || echo /opt/lib >> /etc/ld.so.conf

if [ -z "${D}" ]; then
 ldconfig
fi


The above may work in your local projects, but will likely be rejected from 
submissions to the upstream project as being too fragile.


.

But there is a better way to do this and avoid using ldconfig.  ldconfig was 
designed to be an optimization, but instead it's turned into a hack to cover up 
mistakes.  It's primary use seems to be to cover up when people forget to create 
symlinks and/or don't specify an SONAME within a library.  The secondary use is 
to add library information for libraries residing in non-standard locations... 
and the tertiary use is to simplify the lookup of the packages to avoid 
iterating over a filesystem.


Instead of using ldconfig, inform the application on the locations of the 
non-standard items.  This will then add them to the search path and ldconfig 
will no longer be necessary for a functional system, and instead become the 
optimization it was originally designed to be.


One way to do this, when you are repackaging something you didn't create and 
only have the binaries for, is to create a wrapper script that sets 
"LD_LIBRARY_PATH=" and then executes the action binary..


or

If you are doing the compilation, use a built-in RPATH to specify where your 
application libraries exist.  See: http://itee.uq.edu.au/~daniel/using_origin/ 
for a good explanation of what to pass to the linker and how to use "$ORIGIN" to 
make it easier -- and your application relocatable on the target.  But in short 
you hard-code at compile time the location of your libraries based on the 
location of your executables.


--Mark


Regards,

Marc


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


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

Re: [yocto] Adding line to ld.so.conf

[Mark Hatle]

On 12/2/11 10:08 AM, Michael E Brown wrote:

On Mon, 2011-11-21 at 09:35 -0600, Marc Ferland wrote:

Hi,

What's the proper way to add a line to the ld.so.conf file for a new
library I am adding?


Does yocto support /etc/ld.so.conf.d/ (like every other distro out there
from the past 7 years or so?)

You could just drop a file into that directory with the lines you want
rather than editing the global file.


This is accomplished by having the following line in the /etc/ld.so.conf file.

include ld.so.conf.d/*.conf

However, this then still requires the file to exist on the target filesystem. 
I've got many systems where ld.so.conf simply doesn't exist, nor do I want it to.


See my previous reply on a better was to resolve the issue using rpath and/or 
proper soname handling inside of the libraries.


--Mark



--
Michael

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


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

[yocto] prelink-cross project update

[Mark Hatle]

A new version of the prelink-cross has been pushed to the repository.

There are no upstream changes to the main prelink component, all changes are 
specific to the cross functionality.  Below is the Changelog:


2011-12-08  Mark Hatle 
* rtld/rtld.c: Fix an issue where missing objects would trigger
  an assert in dl-version.c
* rtld/rtld.h: Add _dl_new_object prototype
* rtld/rtld.c: Add support for $ORIGIN, $PLATFORM and $LIB.
  Note: $PLATFORM = ""
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Poky-Build error

[Mark Hatle]

On 12/20/11 2:33 AM, Navani Kamal Srivastava wrote:

Hi,

We are facing the problem when we are compiling poky-bernard5.0 –( bitbake –v –b
poky-image-eb.bb )




Log data follows:

|
/home/prashanth/yocto/poky-bernard-5.0/build/tmp/work/mx35pdk-poky-linux-gnueabi/poky-image-eb-1.0-r0/temp/run.do_rootfs.9800:
line 91: makedevs: command not found

| ERROR: Function 'do_rootfs' failed (see
/home/prashanth/yocto/poky-bernard-5.0/build/tmp/work/mx35pdk-poky-linux-gnueabi/poky-image-eb-1.0-r0/temp/log.do_rootfs.9800
for further information)


Your "poky-image-eb.bb" is attempting to run the makedevs command, but 
apparently it hasn't been built.  Check your logs for a makedevs-native.  If 
that hasn't been built, then it appears something is wrong with your 
configuration.  makedevs-native should be a dependency inherited by the 
image.bbclass.


Note on mailing list etiquette, please stop putting the trailing lines in your 
email.  This is a public mailing list, it is not for your companies "Internal 
Use", not is it reasonable to consider email send to a public list confidential 
in any way.



*This mail is classified as: ( ) L&T Proprietary ( ) L&T Confidential (X) L&T
Internal Use ( ) L&T General Business
This email may contain confidential or privileged information for the intended
recipient(s). If you are not the intended recipient, please do not use or
disseminate the information, notify the sender and delete it from your system.



*Larsen & Toubro Limited

www.larsentoubro.com

*This Email may contain confidential or privileged information for the intended
recipient (s) If you are not the intended recipient, please do not use or
disseminate the information, notify the sender and delete it from your system.


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


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

Re: [yocto] building Yocto on Fedora 14 vs. Ubuntu 11.10

[Mark Hatle]

On 1/5/12 9:59 AM, Jim Abernathy wrote:

I'm finding differences between the number of task for building
meta-cedartrail on ubuntu 11.10 vs. doing the same thing on Fedora 14
and wondered if this is a problem.

On a clean build of core-image-sato, the first section has 63 tasks on
Ubuntu 11.10, but 126 tasks on Fedora 14.  126 is the number I remember
seeing for the first section of the build on other Sato builds.

Is this an issue? is this caused by the different development O/S's?

BTW the second part of the build has 4426 tasks on Ubuntu 11.10 and also
on Fedora 14.


In the bitbake wrapper (scripts/bitbake), there is a check to see if the host 
version of tar is greater then 1.23.  If it is not, then tar is added to the 
early set of tasks.  This likely is the cause of the different task sets you see.


--Mark


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


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

Re: [yocto] Can't build util-linux

[Mark Hatle]

I'm getting the same error.  There is a workaround:

Add the following to your local.conf

WARN_QA = "ldflags useless-rpaths rpaths"

A new QA check went in, and it appears to be missing part of the merge.

(WARN_QA is normally defined as:
WARN_QA ?= "ldflags useless-rpaths rpaths unsafe-references-in-binaries 
unsafe-references-in-scripts")


On 1/5/12 6:49 AM, Gary Thomas wrote:

Using a freshly updated master

OE Build Configuration:
BB_VERSION= "1.15.0"
TARGET_ARCH   = "arm"
TARGET_OS = "linux-gnueabi"
MACHINE   = "beagleboard"
DISTRO= "poky"
DISTRO_VERSION= "1.1+snapshot-20120105"
TUNE_FEATURES = "armv7a vfp neon cortexa8"
TARGET_FPU= "vfp-neon"
meta
meta-yocto= "master:5aabdbaff7b8be319a86c5e33cc2eb8c2e4aa2ef"

| NOTE: DO PACKAGE QA
| NOTE: Checking Package: util-linux-agetty
| ERROR: Error executing a python function in 
/tmp/poky-multi/meta/recipes-core/util-linux/util-linux_2.20.1.bb:
| AttributeError: 'module' object has no attribute 'check_output'
|
| ERROR: The stack trace of python calls that resulted in this 
exception/failure was:
| ERROR:   File "do_package_qa", line 68, in
| ERROR:
| ERROR:   File "do_package_qa", line 57, in do_package_qa
| ERROR:
| ERROR:   File "insane.bbclass", line 19, in package_qa_walk
| ERROR:
| ERROR:   File "insane.bbclass", line 17, in 
package_qa_check_unsafe_references_in_binaries
| ERROR:
| ERROR: The code that was being executed was:
| ERROR:  0064:bb.fatal("QA run found fatal errors. Please consider 
fixing them.")
| ERROR:  0065:bb.note("DONE with PACKAGE QA")
| ERROR:  0066:
| ERROR:  0067:
| ERROR:  *** 0068:do_package_qa(d)
| ERROR:  0069:
| ERROR: (file: 'do_package_qa', lineno: 68, function:)
| ERROR:  0053:errorchecks.append(g[testmatrix[e]])
| ERROR:  0054:
| ERROR:  0055:bb.note("Checking Package: %s" % package)
| ERROR:  0056:path = "%s/%s" % (pkgdest, package)
| ERROR:  *** 0057:if not package_qa_walk(path, warnchecks, 
errorchecks, skip, package, d):
| ERROR:  0058:walk_sane  = False
| ERROR:  0059:if not package_qa_check_rdepends(package, pkgdest, 
skip, d):
| ERROR:  0060:rdepends_sane = False
| ERROR:  0061:
| ERROR: (file: 'do_package_qa', lineno: 57, function: do_package_qa)
| ERROR: Function 'do_package_qa' failed
NOTE: package util-linux-2.20.1-r1: task do_package: Failed

Ideas?



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

Re: [yocto] Trying to compile mono on target for machine crownbay

[Mark Hatle]

On 1/5/12 3:52 PM, autif khan wrote:

I bitbaked core-image-sato-sdk, copied it to the target disk and tried
to build mono natively on the target machine and I got the following
error:

libtool: link: cannot find the library `=/usr/lib/libglib-2.0.la' or
unhandled argument `=/usr/lib/libglib-2.0.la'


The version of libtool you are currently using is damaged in some way.  I 
suspect the program is falling back and trying to use either a local version or 
the host-system version.


The libtool located within the OE/Poky environment understands that when a "=" 
is predicating a path, it means locate the item within the sysroot at the 
following path.  Since the error indicates it doesn't understand that concept, 
it appears that that version of libtool is broken.


Normally the autotools class will deal with this situation for you.  Simply 
inheriting autotools class usually does it.


--Mark


the filesystem does have a /usr/lib/libglib-2.0.la and it seems to be valid

I am not sure why there is a leading '=' in the path. Needless to say
- mono builds fine on ubuntu, so it is unlikely (not impossible) to be
a mono build issue.

Has anyone seen anything like this with mono or some other piece of software?

Thanks

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


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

Re: [yocto] [Announcement] Cedartrail BSP available.

[Mark Hatle]

On 1/11/12 11:21 AM, James Abernathy wrote:

What is the purpose of building the provided images with time limited kernel?
Can I assume that a standard build of the unchanged meta-cedartrail BSP will use
the non-tlk kernel?


Simple reason, the creator of the BSP wants you to configure and build your own 
kernel.  The time limited kernel is for evaluation purposes to see if this is 
what you want, before you build it yourself.


--Mark


Jim A

On Wed, Dec 28, 2011 at 6:02 PM, Flanagan, Elizabeth
mailto:elizabeth.flana...@intel.com>> wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

All,

We are pleased to announce the release of Intel-based board support
packages built from Yocto 1.1 "Edison" for the Intel® Atom™ Processor
N2000 and D2000 Series-based Platform (CEDAR TRAIL).

This BSP are available for download at:


http://www.yoctoproject.org/download/bsp/intel%C2%AE-atom%E2%84%A2-processor-n2000-and-d2000-series-based-platform-cedar-trail

Please note that the provided images were built using the meta-tlk
layer (time limited kernel). Build instructions to build non-tlk
images are provided in the meta-intel/meta-cedartrail/README for these
machines.

META-CEDARTRAIL 1.1 RELEASE

Version: 1.1 "Edison"
md5sum: 777150ce79d5d1cc916410f7d17741e1
Location:

http://www.yoctoproject.org/download/bsp/intel%C2%AE-atom%E2%84%A2-processor-n2000-and-d2000-series-based-platform-cedar-trail

- --
Elizabeth Flanagan
Yocto Project
Build and Release

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJO+5kmAAoJEEyK+E/MEkQPpqkH/iqYOrfxPd1fEcTbw3LXY+re
1H8zOglldc5yPhkhX2PmqkfI28OJwMOiUc3oooYRGeEpGg59SxQSqSImVwf3nmgn
wK933o5FC37M+1fIZsySNNf6Maj5IAExKN1Wu1V56Onf/1wq77kJ/NkvPq62ig5n
lZzKA2C1Red/4NuKKIuTEWj/3e5365XhBkbJHxaRECrIw3fD2bBIj49C3tVAkIUX
+ijIO56UR/qgHfRulUowtarAfCP/xADOnLnOZ9yvv7JEsaekrMReYZlGqEeF/TL+
M6v3b/27OwgF2ohCN3Ib7YnaFTR5g9fXwa//YMLuKm6quL+hafgzxJ2OCOxlo08=
=eKdg
-END PGP SIGNATURE-
___
yocto mailing list
yocto@yoctoproject.org 
https://lists.yoctoproject.org/listinfo/yocto




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


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

Re: [yocto] i486sx machine porting from oe-classic

[Mark Hatle]

On 1/20/12 8:07 AM, Andrea Galbusera wrote:

Hi,

In oe-classic there used to be a machine configuration for an i486sx
based machine called vortex86sx. In the past I was successful in
building a running image for such a target. Since I'd like to make a
new system based on vortex, my goal is to leverage the whole Yocto
Project infrastructure and port that old configuration to a BSP layer.
This will save me a lot of time in supporting developers with SDKs and
so.

Since I could not find any BSP based on hardware older than i586 in
recent Yocto trees, I'm concerned about this. Do you know of any
obstacle in doing such a port? I'm mainly interested in building
images with no graphics for that target: core-image-minimal is a
reasonable reference for me.

My plan was to initially lay out a new BSP by following guidelines
from Development Manual and BSP Guide. Then, what I suspect to be a
little trickier for my expertise, is the porting of the original
tune-i486sx.inc file to the current Yocto infrastructure. Is there any
document I can leverage to map the variables defined in the
oe-classic's syntax to the current ones for such a machine
configuration file?


A few things you will need.. a tune file for the CPU, and a tune file for the 
machine/bsp... and you'll have to make sure that eglibc/Linux can still run on 
that machine.


I know a while back some changes were made to the GNU toolchain, include gcc to 
change default optimization levels and such, I don't know if this negatively 
impacted the ability to generate i486 compatible code.



The original i486 tune file was defining the following:

TARGET_ARCH = "i486"
TARGET_CC_ARCH = "-march=i486"
PACKAGE_EXTRA_ARCHS = "486sx"
BASE_PACKAGE_ARCH = "486sx"
FEED_ARCH = "${BASE_PACKAGE_ARCH}"

Are they still valid variables? Do I need any more?


Variables have changed.  The following is likely what you want (not tested of 
course) meta/conf/machine/include/tune-i486.inc (based off of tune-i586):


DEFAULTTUNE ?= "i486"
TUNE_PKGARCH_TMP = "${@bb.utils.contains("TUNE_FEATURES", "m32", "x86", 
"x86_64", d)}"
TUNE_PKGARCH ?= "${@bb.utils.contains("TUNE_FEATURES", "i486", "i486", 
TUNE_PKGARCH_TMP, d)}"


require conf/machine/include/ia32/arch-ia32.inc

# Extra tune features
TUNEVALID[i486] = "Enable i486 specific processor optimizations"
TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "i486", "-march=i486", "", 
d)}"


# Extra tune selections
AVAILTUNES += "i486"
TUNE_FEATURES_tune-i486 ?= "${TUNE_FEATURES_tune-x86} i486"
BASE_LIB_tune-i486 ?= "lib"
PACKAGE_EXTRA_ARCHS_tune-i486 = "${PACKAGE_EXTRA_ARCHS_tune-x86} i386 i486"

--Mark


Thank you in advance. Regards,
Andrea
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


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

Re: [yocto] Do we have core-image-lsb-core/c++?

[Mark Hatle]

On 2/1/12 10:47 PM, Ni Qingliang wrote:

Hi, ALL:
I'm trying to create a custom image, which is compatible with LSB-core/C
++. The core-image-lsb seems like contain the GUI related packages.
The question is: Do we have core-image-lsb-core or core-image-lsb-c++?




The C++ library should be specified in one of the task definitions in 
tasks/task-core-lsb.bb


However, I'm not seeing it there... it's likely an oversight -- or one of the 
existing frameworks is already adding it so it was necessary?


(Note, I doubt the existing C++ library will pass the current LSB tests.. there 
are a lot of little things that will likely fail the test harness.)


The image "core-image-lsb", is intended to have all of the LSB components in it, 
including the C++ items.  There is now LSB recognized "subset" of images for 
validation.. it's an all or nothing situation.


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

Re: [yocto] needed site is down???

[Mark Hatle]

On 2/2/12 10:08 AM, jfabernathy wrote:

On 02/01/2012 10:59 PM, jfabernathy wrote:

Am I the only one seeing this dead link?  I'm building from master and
can't get to this link that draws the error:

http://cgit.freedesktop.org/libva/snapshot/libva-1.0.12.tar.bz2

I'm building crownbay bsp with core-image-sato.

Jim A


I can't seem to build anything that requires something from
cgit.freedesktop.org.  The whole site seems to be down.  Is there a mirror?


Using the standard poky distribution configuration, you should be connecting to 
our mirrors.


meta-yocto/conf/distro/poky.conf has the settings.  All of the upstream packages 
should be mirrored there.  If they are not, then please let us know and we'll 
work on resolving any missing files.


--Mark


JIm A

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


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

[yocto] prelink-cross project update

[Mark Hatle]

A new version of the prelink-cross has been pushed to the repository.

This version fixes a number of minor bugs found during development, it is also 
believed to resolve bug #1808 relating to ARM prelinking, and adds support for 
x86_64's x32 ABI.


Special thanks to Mentor Graphics for contributing the ARM TLS fix.

There were no upstream changes to the main prelink component, all changes are
specific to the cross functionality.  Below is the Changelog, since the last 
update:

2011-12-21  Mark Hatle 
* src/arch-x86_64.c: Add support for x32 ABI

2012-02-02  Mark Hatle 
Integrate dwarf2 signal frame patch:

2010-05-10  Paul Brook  

* src/dwarf2.c (adjust_dwarf2_frame): Skip 'S' augmentation.

2012-02-01  Mark Hatle 
* configure.in: Fix enabling and disabling of SE Linux support

2012-01-26  Mark Hatle 
* elf.h, rtld/dl-lookupX.h, rtld/rtld.c: Sync to eglibc 2.15

Integrate R_ARM_TLS_DESC relocation support patch:

2011-04-13  Maciej W. Rozycki  

* src/prelink.h (DT_TLSDESC_PLT, R_ARM_TLS_DESC): New macros.
(DSO): Add info_DT_TLSDESC_PLT member.
(DT_TLSDESC_PLT_BIT): New macro.
* src/arch-arm.c (arm_prelink_rel, arm_prelink_rela): Handle
R_ARM_TLS_DESC relocation.
(arm_prelink_conflict_rel, arm_prelink_conflict_rela): Likewise.
(arm_rel_to_rela): Likewise.
(arm_undo_prelink_rel): Likewise.
(arm_reloc_class): Likewise.
* src/dso.c (read_dynamic): Handle DT_TLSDESC_PLT dynamic tag.

* src/prelink.h: add missing prototypes for wrap_listxattr,
wrap_getxattr, wrap_setxattr

2012-01-04  Mark Hatle 
* exec.c: Check that a section is larger then 0 bytes when
  determining the section to segment mapping.  This matches
  the behavior of elfutils - readelf.  Otherwise an empty
  PROGBITS section at the end of a segment will cause a
  failure.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] prelink-cross project update

[Mark Hatle]

On 2/3/12 1:01 AM, Khem Raj wrote:

Hi Mark

Good work. Could you also forward this to oe-core ml ?


After I've vetted everything with the integration into oe-core, I will send this 
out as part of the review request.


--Mark


Thx
-K

On Thu, Feb 2, 2012 at 10:48 AM, Mark Hatle  wrote:

A new version of the prelink-cross has been pushed to the repository.

This version fixes a number of minor bugs found during development, it is
also believed to resolve bug #1808 relating to ARM prelinking, and adds
support for x86_64's x32 ABI.

Special thanks to Mentor Graphics for contributing the ARM TLS fix.

There were no upstream changes to the main prelink component, all changes
are
specific to the cross functionality.  Below is the Changelog, since the last
update:

2011-12-21  Mark Hatle
* src/arch-x86_64.c: Add support for x32 ABI

2012-02-02  Mark Hatle
Integrate dwarf2 signal frame patch:

2010-05-10  Paul Brook

* src/dwarf2.c (adjust_dwarf2_frame): Skip 'S' augmentation.

2012-02-01  Mark Hatle
* configure.in: Fix enabling and disabling of SE Linux support

2012-01-26  Mark Hatle
* elf.h, rtld/dl-lookupX.h, rtld/rtld.c: Sync to eglibc 2.15

Integrate R_ARM_TLS_DESC relocation support patch:

2011-04-13  Maciej W. Rozycki

* src/prelink.h (DT_TLSDESC_PLT, R_ARM_TLS_DESC): New macros.
(DSO): Add info_DT_TLSDESC_PLT member.
(DT_TLSDESC_PLT_BIT): New macro.
* src/arch-arm.c (arm_prelink_rel, arm_prelink_rela): Handle
R_ARM_TLS_DESC relocation.
(arm_prelink_conflict_rel, arm_prelink_conflict_rela): Likewise.
(arm_rel_to_rela): Likewise.
(arm_undo_prelink_rel): Likewise.
(arm_reloc_class): Likewise.
* src/dso.c (read_dynamic): Handle DT_TLSDESC_PLT dynamic tag.

* src/prelink.h: add missing prototypes for wrap_listxattr,
wrap_getxattr, wrap_setxattr

2012-01-04  Mark Hatle
* exec.c: Check that a section is larger then 0 bytes when
  determining the section to segment mapping.  This matches
  the behavior of elfutils - readelf.  Otherwise an empty
  PROGBITS section at the end of a segment will cause a
  failure.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


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

Re: [yocto] pseudo interaction issue

[Mark Hatle]

We're looking into this issue.  You should never get the "pseudo: You must set 
the PSEUDO_PREFIX environment variable to run pseudo." message.  This means 
something appears to have avoided the wrappers.


I'll let you know once we figure out something.

--Mark

On 2/17/12 9:35 AM, Paul Eggleton wrote:

Hi all,

I'm trying to extend buildhistory to write out the metadata revisions just
before it does the commit to the buildhistory repository, and I'm having some
pseudo-related trouble. The structure is a little unusual, in that the
execution flow is an event handler that calls a shell function (via
bb.build.exec_func()) and during parsing this function an ${@...} reference to
a python function is evaluated, which then calls os.popen(), at which point I
get the error "pseudo: You must set the PSEUDO_PREFIX environment variable to
run pseudo."

I don't need pseudo at this stage. I've tried setting PSEUDO_DISABLED=1 and
even PSEUDO_UNLOAD=1 just prior to the os.popen() call (or within it) and
despite evidence that pseudo is taking notice of these being set in other
contexts (when the function is called from elsewhere) even when doing this I
still get the error above. I could rearrange the structure to avoid this
execution flow however that would bar me from reusing existing code that we
have for getting the metadata revision.

Any suggestions?

Cheers,
Paul



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

Re: [yocto] Minutes: Yocto Project Technical Team Meeting - Tuesday, March 13, 2012 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada).

[Mark Hatle]

On 3/13/12 1:54 PM, McClintock Matthew-B29882 wrote:

On Tue, Mar 13, 2012 at 1:25 PM, Liu, Song  wrote:

* Opens - 10 min
  - Mark: Reusing sstate cache, missing a testcase: found a bug in 1.1, found a 
new bug in 1.2, try to use the st cache, the compiler will try to use compiler 
from previous compiler.
Sean: Mentor are testing sstate cache. There is at least one issue 
identified. Sean to take a look at what's going on, make sure we are augmenting 
what's done. We should see more mentor involvement in upstream.
RP: Many sstate issues are known. There are warning messages the team can 
help to fix and that should improve sstate stability.


Are any of these sstate cache issues specific to 1.1.1 or new issues?
(Just trying to track fixes to 1.1.1)

-M


1.1.1 issue is: 2041

The 1.2 issue is: 2074/2082  (former is the bug, later is the new test case)

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

Re: [yocto] which yocto doc explains bitbake assignment variations?

[Mark Hatle]

On 3/29/12 4:47 PM, Robert P. J. Day wrote:


   somewhere, i'm assuming there's a decent explanation of the
different bitbake assignment variations (=, ?=, ??=), but i don't
immediately see it, and i think it's pretty important that that's
explained properly.  pointer?

rday



The bitbake manual has this information in it.  I don't know of a current 
version that is posted online, but you should be able to generate it from within 
bitbake itself.


(and older version: http://docs.openembedded.org/bitbake/html/)

But for the record the variations:

Immediate, overwrite existing values:
  variable = "value"

Conditional, only if not previously set:
  variable ?= "value"

Conditional, late evaluation -- i.e. at the end, only if set:
  variable ??= "value"

Immediate, expand variables immediately:
  variable := "${value}"

Append with spaces:
  variable += "value"

Prepend with spaces:
  variable =+ "value"

Append without spaces:
  variable .= "value"

Prepend without spaces:
  variable =. "value"

Append "late" evaluation:
  variable_append = "value"

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

Re: [yocto] Moving angstrom under the yocto banner

[Mark Hatle]

On 3/30/12 1:44 PM, Koen Kooi wrote:

Hi,

RP said I should raise this on the yocto lists, so here it is:

The Angstrom core team would like to move angstrom under the yocto banner so
we can formally claim to be 'yocto'.


For it to be on the yocto project web site, it just need to have the layers 
hosted on the git.yoctoproject.org.  But there is no "yocto".. It's the Yocto 
Project, Poky, or specific git repositories.  There is no reason we can't have 
an angstrom repository.  It could be in a similar format to the Poky repository 
(everything combined for a single download), or it could be a layer [or layers] 
that sit on top of Poky.




What is the process to make that happen? I suspect OSVs will need to know as
well, since lately yocto is being defined as 'poky + 1 bsp layer' which makes it
impossible to provide any added value if you want to keep calling it 'yocto' to
your customers.


I've never seen it defined as that.  I've presented on numerous occasions that 
end users using the Yocto Project build environment, Poky, should expect to add 
1 or more layers to Poky.  Usually I present that would be 2 or 3 layers 
depending on their projects.  1 (or more) BSP layers, 1 (or more) userspace 
layers, and 1 (or more) internal project/device layers.


External items come in layers and should not be modified, to ease long term 
maintenance and upgrading.  Local changes should be made in one or more layers 
depending on responsibilities, work flow and project requirements.


What I personally would like to see is Angstrom being one or more layers that 
define a new distribution that can be added to Poky (or oe-core...)


--Mark



regards,

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


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

Re: [yocto] Moving angstrom under the yocto banner

[Mark Hatle]

On 3/30/12 2:33 PM, Koen Kooi wrote:


Op 30 mrt. 2012, om 12:26 heeft Mark Hatle het volgende geschreven:


On 3/30/12 1:44 PM, Koen Kooi wrote:

Hi,

RP said I should raise this on the yocto lists, so here it is:

The Angstrom core team would like to move angstrom under the yocto banner so
we can formally claim to be 'yocto'.


For it to be on the yocto project web site, it just need to have the layers hosted on the 
git.yoctoproject.org.  But there is no "yocto".. It's the Yocto Project, Poky, 
or specific git repositories.  There is no reason we can't have an angstrom repository.  
It could be in a similar format to the Poky repository (everything combined for a single 
download), or it could be a layer [or layers] that sit on top of Poky.


Why on top of poky? I do not want poky, nor do my customers, oe-core is what
we need and want. This proposal to move angstrom under yocto is targeted at
eliminating 'poky' from the stack while still being able to say 'yocto'.


Poky is a repository made up of bitbake + oe-core + meta-yocto, as well as a 
distribution definition (in meta-yocto).  I assume angstrom has it's own 
distribution definition.


So my question is why NOT on top of Poky (the repository, not distribution 
definition)?




We both know that saying it is 'yocto' is wrong and misleading, but that's
what users are asking for and yocto advocates seem to push. Just watch the ELC
videos for yocto related presentations, 'yocto' and 'poky' are used
interchangeably in most of them.

A 'reference' should be just that, a reference, not a mandated part.


It's hard to call something Yocto Project based unless it used something from 
the Yocto Project.  meta-yocto being on of those components.


There is enough confusion about yocto vs poky vs..  It's slowly being reconciled 
and defined.. but it's a slow process for all of us.


--Mark



regards,

Koen


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

Re: [yocto] 1.2_M2 build fails for syslinux_4.03.bb for Romley BSP

[Mark Hatle]

On 4/9/12 5:36 PM, Bodke, Kishore K wrote:

Hi ,

Poky and meta-intel for 1.2_M2 build is failing for syslinux_4.03 recipe.

Did anyone saw this for other BSPs?

ERROR: Function 'do_compile' failed (see
/home/tmelab/yocto/poky/poky-1.2_M2.final/build/tmp/work/x86_64-linux/syslinux-native-4.03-r3/temp/log.do_compile.53231
for further information)

ERROR: Logfile of failure stored in:
/home/tmelab/yocto/poky/poky-1.2_M2.final/build/tmp/work/x86_64-linux/syslinux-native-4.03-r3/temp/log.do_compile.53231

Log data follows:

| ERROR: Function 'do_compile' failed (see
/home/tmelab/yocto/poky/poky-1.2_M2.final/build/tmp/work/x86_64-linux/syslinux-native-4.03-r3/temp/log.do_compile.53231
for further information)

| NOTE: make -j 8
BINDIR=/home/tmelab/yocto/poky/poky-1.2_M2.final/build/tmp/sysroots/x86_64-linux/usr/bin
SBINDIR=/home/tmelab/yocto/poky/poky-1.2_M2.final/build/tmp/sysroots/x86_64-linux/usr/sbin
LIBDIR=/home/tmelab/yocto/poky/poky-1.2_M2.final/build/tmp/sysroots/x86_64-linux/usr/lib
DATADIR=/home/tmelab/yocto/poky/poky-1.2_M2.final/build/tmp/sysroots/x86_64-linux/usr/share
MANDIR=/home/tmelab/yocto/poky/poky-1.2_M2.final/build/tmp/sysroots/x86_64-linux/usr/share/man
INCDIR=/home/tmelab/yocto/poky/poky-1.2_M2.final/build/tmp/sysroots/x86_64-linux/usr/include
CC=ccache gcc installer

| make -r installer-local

| make[1]: Entering directory
`/home/tmelab/yocto/poky/poky-1.2_M2.final/build/tmp/work/x86_64-linux/syslinux-native-4.03-r3/syslinux-4.03'

| make[1]: Nothing to be done for `installer-local'.

| make[1]: Leaving directory
`/home/tmelab/yocto/poky/poky-1.2_M2.final/build/tmp/work/x86_64-linux/syslinux-native-4.03-r3/syslinux-4.03'

| set -e ; for i in libinstaller mtools linux extlinux utils; do make -r -C $i
all ; done

| make[1]: Entering directory
`/home/tmelab/yocto/poky/poky-1.2_M2.final/build/tmp/work/x86_64-linux/syslinux-native-4.03-r3/syslinux-4.03/libinstaller'

| make[1]: Nothing to be done for `all'.

| make[1]: Leaving directory
`/home/tmelab/yocto/poky/poky-1.2_M2.final/build/tmp/work/x86_64-linux/syslinux-native-4.03-r3/syslinux-4.03/libinstaller'

| make[1]: Entering directory
`/home/tmelab/yocto/poky/poky-1.2_M2.final/build/tmp/work/x86_64-linux/syslinux-native-4.03-r3/syslinux-4.03/mtools'

| make[1]: Nothing to be done for `all'.

| make[1]: Leaving directory
`/home/tmelab/yocto/poky/poky-1.2_M2.final/build/tmp/work/x86_64-linux/syslinux-native-4.03-r3/syslinux-4.03/mtools'

| make[1]: Entering directory
`/home/tmelab/yocto/poky/poky-1.2_M2.final/build/tmp/work/x86_64-linux/syslinux-native-4.03-r3/syslinux-4.03/linux'

| ccache gcc -Wp,-MT,syslinux.o,-MMD,./.syslinux.o.d -W -Wall
-Wstrict-prototypes -D_FILE_OFFSET_BITS=64 -g -O0 -Dalloca=malloc -I. -I..
-I../libinstaller -c -o syslinux.o syslinux.c

| ccache gcc -Wp,-MT,syslxcom.o,-MMD,./.syslxcom.o.d -W -Wall
-Wstrict-prototypes -D_FILE_OFFSET_BITS=64 -g -O0 -Dalloca=malloc -I. -I..
-I../libinstaller -c -o syslxcom.o ../libinstaller/syslxcom.c

| In file included from ../libinstaller/linuxioctl.h:22:0,

| from ../libinstaller/syslxcom.c:33:

| /usr/include/linux/ext2_fs.h:178:41: error: unknown type name 'umode_t'


This looks like a bug in the libinstaller component of syslinux.  It is relying 
on the include files from the host system's kernel to gain access to kernel 
specific headers.


Instead this thing should be cleaned of references to /usr/include/linux, and 
local versions (that are known to be correct) should be provided.


Please be sure to file a bug in the bugzilla.yoctoproject.org system -- or if 
you can't do that for some reason, let me know and I'll file it.


--Mark


| make[1]: *** [syslxcom.o] Error 1

| make[1]: *** Waiting for unfinished jobs

| In file included from ../libinstaller/linuxioctl.h:22:0,

| from syslinux.c:50:

| /usr/include/linux/ext2_fs.h:178:41: error: unknown type name 'umode_t'

| make[1]: *** [syslinux.o] Error 1

| make[1]: Leaving directory
`/home/tmelab/yocto/poky/poky-1.2_M2.final/build/tmp/work/x86_64-linux/syslinux-native-4.03-r3/syslinux-4.03/linux'

| make: *** [installer] Error 2

| ERROR: oe_runmake failed

NOTE: package syslinux-native-4.03-r3: task do_compile: Failed

NOTE: package mtools-native-4.0.17-r0: task do_install: Started

NOTE: package
linux-libc-headers-yocto-2.6.37+git-1+69cfbdf9f1ff461a75e5b77d6d7ba35e97db4cc3_1+69cfbdf9f1ff461a75e5b77d6d7ba35e97db4cc3-r4:
task do_validate_branches: Started

NOTE: package
linux-libc-headers-yocto-2.6.37+git-1+69cfbdf9f1ff461a75e5b77d6d7ba35e97db4cc3_1+69cfbdf9f1ff461a75e5b77d6d7ba35e97db4cc3-r4:
task do_validate_branches: Succeeded

NOTE: package gcc-cross-initial-4.6.2+svnr181430-r20: task do_populate_sysroot:
Started

NOTE: Running task 2732 of 4771 (ID: 1998,
/home/tmelab/yocto/poky/poky-1.2_M2.final/meta/recipes-kernel/linux-libc-headers/linux-libc-headers-yocto_git.bb,
do_patch)

NOTE: Running task 2733 of 4771 (ID: 4286,
/home/tmelab/yocto/poky/poky-1.2_M2.final/meta/recipes-devtools/gcc/gcc-cross-initial_4.6.bb,
do

Re: [yocto] Yocto Project 1.2 Beta testing instructions

[Mark Hatle]

On 4/10/12 4:18 AM, Paul Eggleton wrote:

On Wednesday 04 April 2012 18:08:58 Liu, Song wrote:

Can someone help answer the following question? This happens during Boon
Pin's beta testing using the build at:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/snapshot/poky-8e9f6fc77ac476
3f4ed1f6e7b720420c220ba6e2.tar.bz2 .
...
| Processing task-core-boot...
| Manifest:
| /home/nemo/yp-beta-build/tmp/work/qemux86-poky-linux/core-image-minimal-1
| .0-r0/rootfs/install/install.manifest local: 1: -Uhv: bad variable name

NOTE: package core-image-minimal-1.0-r0: task do_rootfs: Failed
ERROR: Task 8
(/home/nemo/yp-beta/meta/recipes-core/images/core-image-minimal.bb,
do_rootfs) failed with exit code '1' NOTE: Tasks Summary: Attempted 1329
tasks of which 287 didn't need to be rerun and 1 failed.


Sorry for the late reply, presumably this issue is still present?


Maybe I am missing rpm packages in ubuntu ?


You don't need to install rpm on the host system, we build rpm-native for
that.

Mark, any clues what could be going wrong here?


I've never seen any problem like this before.  Below is some analysis and a 
question at the very end...


There are only two places in the system where the string -Uhv exists:

package_rpm.bbclass:

rpm_common_comand --replacepkgs \
-Uhv ${target_rootfs}/install/total_solution.manifest

(rpm_common_comand is a shell function it appears... the arguments to the 
function are passed, via $@ to an RPM command)


rootfs_rpm.bbclass:

rootfs_install_packages() {
# The pkg to be installed here is not controlled by the
# package_install_internal_rpm, so it may have already been
# installed(e.g, installed in the first time when generate the
# rootfs), use '--replacepkgs' to always install them
for pkg in $@; do
${RPM} --root ${IMAGE_ROOTFS} -D "_dbpath ${rpmlibdir}" \
-D "__dbi_txn create nofsync private" \
--noscripts --notriggers --noparentdirs --nolinktos \
--replacepkgs -Uhv $pkg || true
done
}

I would guess from the error that it's the one in package_rpm.bbclass that 
failed.. if that is the case, then all I can think of is what shell?  Are we 
using a bash-ism?  Does "dash" on ubuntu have shell functions enabled in it, if 
not that might be the problem.


Please check your system's /bin/sh.. is it a symlink, if so, what does it point 
to?  If it points to "dash", change it to "bash" and see if the error still occurs.


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

Re: [yocto] Yocto Project 1.2 Beta testing instructions

[Mark Hatle]

On 4/10/12 6:06 PM, Khor, Boon Pin wrote:

Hi all

  On my ubuntu 11.10 64bits machines , once I change the default shell to bash 
, the problem solved .


I believe we expect dash to be fully supported, so this is a bug.

Please file a bug in the Yocto Project bugzilla 
(http://bugzilla.yoctoproject.org)  if you are not able to do so, let me know 
and I will file it.


--Mark


Thanks
Boon pin

-Original Message-
From: Mark Hatle [mailto:mark.ha...@windriver.com]
Sent: Wednesday, April 11, 2012 1:22 AM
To: Paul Eggleton
Cc: yocto@yoctoproject.org; Liu, Song; Khor, Boon Pin
Subject: Re: [yocto] Yocto Project 1.2 Beta testing instructions

On 4/10/12 4:18 AM, Paul Eggleton wrote:

On Wednesday 04 April 2012 18:08:58 Liu, Song wrote:

Can someone help answer the following question? This happens during
Boon Pin's beta testing using the build at:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/snapshot/poky-8e9f6fc7
7ac476
3f4ed1f6e7b720420c220ba6e2.tar.bz2 .
...
| Processing task-core-boot...
| Manifest:
| /home/nemo/yp-beta-build/tmp/work/qemux86-poky-linux/core-image-min
| imal-1 .0-r0/rootfs/install/install.manifest local: 1: -Uhv: bad
| variable name

NOTE: package core-image-minimal-1.0-r0: task do_rootfs: Failed
ERROR: Task 8
(/home/nemo/yp-beta/meta/recipes-core/images/core-image-minimal.bb,
do_rootfs) failed with exit code '1' NOTE: Tasks Summary: Attempted
1329 tasks of which 287 didn't need to be rerun and 1 failed.


Sorry for the late reply, presumably this issue is still present?


Maybe I am missing rpm packages in ubuntu ?


You don't need to install rpm on the host system, we build rpm-native
for that.

Mark, any clues what could be going wrong here?


I've never seen any problem like this before.  Below is some analysis and a 
question at the very end...

There are only two places in the system where the string -Uhv exists:

package_rpm.bbclass:

  rpm_common_comand --replacepkgs \
  -Uhv ${target_rootfs}/install/total_solution.manifest

(rpm_common_comand is a shell function it appears... the arguments to the 
function are passed, via $@ to an RPM command)

rootfs_rpm.bbclass:

rootfs_install_packages() {
  # The pkg to be installed here is not controlled by the
  # package_install_internal_rpm, so it may have already been
  # installed(e.g, installed in the first time when generate the
  # rootfs), use '--replacepkgs' to always install them
  for pkg in $@; do
  ${RPM} --root ${IMAGE_ROOTFS} -D "_dbpath ${rpmlibdir}" \
  -D "__dbi_txn create nofsync private" \
  --noscripts --notriggers --noparentdirs --nolinktos \
  --replacepkgs -Uhv $pkg || true
  done
}

I would guess from the error that it's the one in package_rpm.bbclass that failed.. if 
that is the case, then all I can think of is what shell?  Are we using a bash-ism?  Does 
"dash" on ubuntu have shell functions enabled in it, if not that might be the 
problem.

Please check your system's /bin/sh.. is it a symlink, if so, what does it point to?  If it points 
to "dash", change it to "bash" and see if the error still occurs.

--Mark


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

Re: [yocto] [PATCH] Fix QA Issue reported by running bitbake

[Mark Hatle]

On 7/27/13 10:44 AM, Pier Luigi Fiorini wrote:

Fix the following error:
   Variable ALLOW_EMPTY is set as not being package specific, please fix this.


I thought this had already been done.  I'll be going over the meta-selinux 
sometime this week and will verify all of the bad ALLOW_EMPTY entries and other 
version sync have been done.


--Mark


---
  recipes-security/tasks/task-core-selinux.bb | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-security/tasks/task-core-selinux.bb 
b/recipes-security/tasks/task-core-selinux.bb
index 05f8dfc..dda9c50 100644
--- a/recipes-security/tasks/task-core-selinux.bb
+++ b/recipes-security/tasks/task-core-selinux.bb
@@ -8,7 +8,7 @@ PACKAGES = "\
  task-core-selinux \
  "

-ALLOW_EMPTY = "1"
+ALLOW_EMPTY_${PN} = "1"

  RDEPENDS_task-core-selinux = " \
ustr \



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

Re: [yocto] [meta-selinux][PATCH] Fix QA Issue reported by running bitbake

[Mark Hatle]

On 7/31/13 10:05 AM, Mark Hatle wrote:

On 7/27/13 10:44 AM, Pier Luigi Fiorini wrote:

Fix the following error:
Variable ALLOW_EMPTY is set as not being package specific, please fix this.


I thought this had already been done.  I'll be going over the meta-selinux
sometime this week and will verify all of the bad ALLOW_EMPTY entries and other
version sync have been done.


Ahh I had a local version of this patch that I thought had been previously 
pushed.

I've synced this and a few other changes and pushed to the meta-selinux 
repository.

'master' should now be current with oe-core as of this morning.  If you run into 
any problems, please let me know.  (Be sure to have 'meta-selinux' in the 
subject of the email or I might miss it.)


--Mark


--Mark


---
   recipes-security/tasks/task-core-selinux.bb | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-security/tasks/task-core-selinux.bb 
b/recipes-security/tasks/task-core-selinux.bb
index 05f8dfc..dda9c50 100644
--- a/recipes-security/tasks/task-core-selinux.bb
+++ b/recipes-security/tasks/task-core-selinux.bb
@@ -8,7 +8,7 @@ PACKAGES = "\
   task-core-selinux \
   "

-ALLOW_EMPTY = "1"
+ALLOW_EMPTY_${PN} = "1"

   RDEPENDS_task-core-selinux = " \
ustr \



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



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

Re: [yocto] meta-selinux make ALLOW_EMPTY package specific

[Mark Hatle]

On 6/19/13 8:53 AM, Philip Tricca wrote:

Ping.  Any interest in taking this (and the other patch I sent) into
meta-selinux?


My apologies, I thought this had been integrated already.  A similar patch has 
been pushed to the repository for the 'master' branch.  I have not yet validated 
the dylan, but as you indicated it should be needed there as well.


I should have the Dylan version ready and pushed within a few hours.

--Mark


Regards
- Philip

On 06/10/2013 08:54 PM, Philip Tricca wrote:

Hello again,

Again a quick patch to get meta-selinux dylan branch building with oe-core 
dylan.  The QA scripts error'd out complaining that ALLOW_EMPTY in the 
task-core-selinux wasn't packages specific.  Not sure if it's relevant but this 
was with the latest bitbake release branch 1.18.  One line fix below.

Regards,
- Philip

From: Philip Tricca 
Date: Mon, 10 Jun 2013 20:33:32 -0400
Subject: [PATCH 2/2] Make ALLOW_EMPTY package specific to keep QA scripts
  happy.

---
  recipes-security/tasks/task-core-selinux.bb |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-security/tasks/task-core-selinux.bb 
b/recipes-security/tasks/task-core-selinux.bb
index 05f8dfc..dda9c50 100644
--- a/recipes-security/tasks/task-core-selinux.bb
+++ b/recipes-security/tasks/task-core-selinux.bb
@@ -8,7 +8,7 @@ PACKAGES = "\
  task-core-selinux \
  "

-ALLOW_EMPTY = "1"
+ALLOW_EMPTY_${PN} = "1"

  RDEPENDS_task-core-selinux = " \
ustr \





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

Re: [yocto] [meta-selinux][PATCH 1/1] policycoreutils: fix genhomedircon construction

[Mark Hatle]

On 8/1/13 12:25 PM, Joe Slater wrote:

CQID: 418197

Reference /usr/sbin instead of the directory into which
the script is installed on the host.


This patch and the related audit patch have been applied to both master and 
dylan branches.  Thanks!


--Mark


Signed-off-by: Joe Slater 
---
  .../selinux/policycoreutils/scripts_makefile.patch |   26 
  recipes-security/selinux/policycoreutils_2.1.13.bb |3 +-
  2 files changed, 28 insertions(+), 1 deletions(-)
  create mode 100644 
recipes-security/selinux/policycoreutils/scripts_makefile.patch

diff --git a/recipes-security/selinux/policycoreutils/scripts_makefile.patch 
b/recipes-security/selinux/policycoreutils/scripts_makefile.patch
new file mode 100644
index 000..8972474
--- /dev/null
+++ b/recipes-security/selinux/policycoreutils/scripts_makefile.patch
@@ -0,0 +1,26 @@
+policycoreutils: fix genhomedircon generation
+
+The script is put on the target and needs to reference
+the directory in which semodule is installed.
+
+Upstream Status: pending
+
+Signed-off-by: Joe Slater 
+
+--- a/scripts/Makefile
 b/scripts/Makefile
+@@ -8,11 +8,12 @@ LOCALEDIR ?= $(PREFIX)/share/locale
+
+ all: fixfiles genhomedircon chcat
+
++# we want the script to use the user sbin directory on the target
++#
+ genhomedircon:
+   @echo "#!/bin/sh" > genhomedircon
+   @echo >> genhomedircon
+-  @if [ ! -e semodule_path ]; then echo -n "$(USRSBINDIR)/" >> 
genhomedircon; fi
+-  @if [ -e semodule_path ]; then echo -n "`cat semodule_path`/" >> 
genhomedircon; fi
++  @echo -n "$(sbindir)/" >> genhomedircon
+   @echo "semodule -Bn" >> genhomedircon
+
+ install: all
diff --git a/recipes-security/selinux/policycoreutils_2.1.13.bb 
b/recipes-security/selinux/policycoreutils_2.1.13.bb
index 6696357..687347c 100644
--- a/recipes-security/selinux/policycoreutils_2.1.13.bb
+++ b/recipes-security/selinux/policycoreutils_2.1.13.bb
@@ -1,4 +1,4 @@
-PR = "r2"
+PR = "r3"

  include selinux_20120924.inc
  include ${BPN}.inc
@@ -11,4 +11,5 @@ SRC_URI[sha256sum] = 
"34040f06f3111d9ee957576e4095841d35b9ca9141ee8d80aab036cbef
  SRC_URI += "\
file://policycoreutils-revert-restorecon-update-type.patch \
file://policycoreutils-revert-run_init-open_init_pty.patch \
+   file://scripts_makefile.patch \
"



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

Re: [yocto] Package specific version dependencies

[Mark Hatle]

On 8/6/13 4:07 AM, Paul Eggleton wrote:

Hi Francesco,

On Tuesday 06 August 2013 09:55:06 Francesco Del Degan wrote:

Playing with RDEPENDS variable i'm facing the needs to
specify a dependency based on specific version of a package
(greather than, in my specific case).

The underlying package managers supports declaring dependencies
including version relationships, for example:

Rpm:  Requires: package_xxx >= 1.0.27
Deb:  Depends: libc6 (>= 2.2.1)
Okpg: Depends: xfree (>= 6.0), glib2

Is this feature just missing in yocto or it's explicitly denied
for some reason?


This should work, in fact we use it (with =) in conjunction with EXTENDPKGV
when we want to force packages from the same recipe to upgrade in lock-step.


The format for RDEPENDS is slightly different from all three.

dep (= ver)
dep (< ver)
dep (> ver)
dep (<= ver)
dep (>= ver)

(For those familiar with deb style, >> and << is not supported by the oe-core 
dependency set.  This is to avoid confusion as > and < are a lot more obvious.)


The items above are then mapped into their respective format depending on the 
package manager you have selected.


Note:  The version dependency items are not evaluated by bitbake, it only pays 
attention to the package name when determining build dependencies.  You would 
also need to specify (in your distribution or local .conf file) a 
PREFERRED_VERSION_dep = "ver" to ensure the right version is built.


--Mark


Have you tried adding these specifications to an RDEPENDS value?

Cheers,
Paul



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

Re: [yocto] Sending mail from embedded device

[Mark Hatle]

On 8/6/13 9:41 AM, Jack Mitchell wrote:

On 06/08/13 15:31, Gary Thomas wrote:

My embedded device needs to send out email.

I've looked around a bit and I don't see any recipes for a
mail sender, e.g. sendmail or postfix, for Yocto (OE-core).

Have I missed something?  Does anyone have any suggestions?

Surely my application isn't the first that wants to send email...



Would recipes-extended/msmtp do the job? Do you need to run the whole
mail stack or is pushing out emails to an smtp server adequate?



msmtp is provided specifically to be able to send email out.  It should produce 
a binary called "sendmail" that is capable of simply sending email (and 
conforming to LSB requirements.)


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

Re: [yocto] Sending mail from embedded device

[Mark Hatle]

On 8/6/13 10:00 AM, Jack Mitchell wrote:

On 06/08/13 15:50, Mark Hatle wrote:

On 8/6/13 9:41 AM, Jack Mitchell wrote:

On 06/08/13 15:31, Gary Thomas wrote:

My embedded device needs to send out email.

I've looked around a bit and I don't see any recipes for a
mail sender, e.g. sendmail or postfix, for Yocto (OE-core).

Have I missed something?  Does anyone have any suggestions?

Surely my application isn't the first that wants to send email...



Would recipes-extended/msmtp do the job? Do you need to run the whole
mail stack or is pushing out emails to an smtp server adequate?



msmtp is provided specifically to be able to send email out.  It should
produce a binary called "sendmail" that is capable of simply sending
email (and conforming to LSB requirements.)

--Mark


Colour me impressed, I didn't realise it was also a drop-in for sendmail.


Drop in replacement for the 'sendmail' command, but it's not a drop-in for 
'sendmail' the software.  (It only has sending capabilities from what I've been 
told, which is all that is required for the LSB certification.)


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

Re: [yocto] My stuff is missing from rootfs

[Mark Hatle]

On 8/15/13 2:30 PM, Paul D. DeRocco wrote:

From: Saul Wold


On 08/15/2013 11:37 AM, Paul D. DeRocco wrote:
I've done exactly this in a different Yocto-based project,
and it worked.
Now I'm trying to do the same thing in a Gumstix build, and it's not
working. I have a dumb little recipe that merely copies
some files into
particlar places in the rootfs. It adds a systemd service
unit, as well as
.bashrc and .inputrc to /home/root.

The build logs show the recipe being processed, including
the do_install
task which copies the files. No errors are produced. If I
rummage through
build/tmp/work, I can find the fragment of the rootfs containing the
/home/root and /etc/systemd/system directories with my
files in them. Yet no
matter what I try, these things never wind up in the final rootfs.

I've tried clean and cleansstate on the recipe, as well as
on my top-level
recipe. I've bumped PR from r0 to r1. It dutifully
reprocesses my recipe,
with no errors, and I end up with a perfectly functioning
rootfs without
these particular files.

This is a slightly modified version of
gumstix-console-image. I believe it's
based on Danny, as the gumstix Dylan stuff is still a work
in progress.

What could conceivably be wrong?


Where do you add your recipe's generated packages to the image, this
could be in your custom image with an RDEPENDS or via something in
local.conf like CORE_IMAGE_EXTRA_INSTALL_append = " ".

Do you have other recipes that DEPEND or RDEPEND on your recipe?

That might point you in the right direction.


My top level recipe uses IMAGE_INSTALL to add a bunch of packages, including
one whose name matches the name of the recipe that's being processed but
whose output is being ignored. This is exactly what I did in a different
Yocto project, to get a similar recipe to install some similar files, and it
all worked fine.

I've attached the top level recipe and the problematic one, only changing
the project name to "foo" for proprietary reasons.



A simple way to diagnose if your package is even in the install list is to do 
bitbake -e , then scan the output for "PACKAGE_INSTALL".  If your package 
is not listed there, then something has either cleared your configuration or you 
have a typo.


IMAGE_INSTALL_append = " my_package" should work, and generally won't be cleared 
by a recipe.


(Note you should modify IMAGE_INSTALL, which is transformed by the system into 
PACKAGE_INSTALL... modifying PACKAGE_INSTALL can lead to problems.)


--Mark



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



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

Re: [yocto] My stuff is missing from rootfs

[Mark Hatle]

On 8/15/13 7:20 PM, Paul D. DeRocco wrote:

From: Mark Hatle

A simple way to diagnose if your package is even in the
install list is to do
bitbake -e , then scan the output for
"PACKAGE_INSTALL".  If your package
is not listed there, then something has either cleared your
configuration or you
have a typo.

IMAGE_INSTALL_append = " my_package" should work, and
generally won't be cleared
by a recipe.


It's there, and it's all working now. I've had things break in odd ways
before, and recover when I rebuilt. This time it took a couple of tries.

What makes it frustrating is that I'm building on a wimpy Atom system.
I've been on the verge of buying a killer system just to do builds, but I
keep thinking, maybe I'll only need to do this another dozen or so times
and then I'll be done, in which case it wouldn't be a good investment.


(Note you should modify IMAGE_INSTALL, which is transformed
by the system into
PACKAGE_INSTALL... modifying PACKAGE_INSTALL can lead to problems.)


I don't think that all the various ways to append stuff will ever make
sense to me. Currently, I'm using IMAGE_INSTALL += "..." in my top level
recipe, and it works. I don't know what IMAGE_INSTALL_append does
differently.



Difference between IMAGE_INSTALL += and IMAGE_INSTALL_append is when the process 
happens.


IMAGE_INSTALL += happens immediately, and if something later in the resolution 
does "IMAGE_INSTALL = " then you can lose the value.


IMAGE_INSTALL_append happens at the very end of variable resolution.. i.e.:

IMAGE_INSTALL_append = " mypkg"
IMAGE_INSTALL = "foo"
IMAGE_INSTALL += "bar"
IMAGE_INSTALL = "foobar"

Your end result will be "foobar mypkg"...

(USUALLY the '=' in the example above actually indicates a bug of some kind.. 
but it does happen.)


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

[yocto] [meta-selinux] Updated meta-selinux -- master-next

[Mark Hatle]

I have updated meta-selinux, and placed the update into the 'master-next' 
branch.

This was locally tested with Poky as of commit 
853bc53cd58a621918f0e5ce662dba263d1befb4.


Note, when building the core-image-selinux, the internal refpolicies cause a lot 
of failures.  I'm not an expert on how this should be configured, so I'm looking 
for help/patches from others.


If you know of any other additional patches that should be applied, or are able 
to help with the refpolicies, please let me know!


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

Re: [yocto] Happy Birthday, Yocto Project

[Mark Hatle]

On 11/15/13, 1:54 PM, Mark Hatle wrote:

On 11/14/13, 9:58 PM, Jeff Osier-Mixon wrote:

Hm, a day that will live in infamy indeed

On Fri, Nov 15, 2013 at 3:09 AM, Philip Balister  wrote:

On 11/14/2013 08:22 PM, Robert P. J. Day wrote:

On Thu, 14 Nov 2013, Jeff Osier-Mixon wrote:


Happy birthday, Yocto Project!


what's a birthday without cake?

http://www.instructables.com/id/Brain-Cake/

rday



Berlios suggests bitbake was born on Dec 7, 2004. So in a few weeks we
will celebrate the 9'th birthday of the OpenEmbedded build system.


I found a presentation that seems to have a bit more history in it.

OpenEmbedded & BitBake - Denx.
www.denx.de/wiki/pub/ELDKHistory/.../OpenEmbeddedv1.ppt‎
December 2004: OpenEmbedded is split up into the BitBake build system and the
OpenEmbedded metadata. OpenZaurus. OpenEmbedded is the successor to  ..

http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=6&ved=0CE0QFjAF&url=http%3A%2F%2Fwww.denx.de%2Fwiki%2Fpub%2FELDKHistory%2FDocumentationLinks%2FOpenEmbeddedv1.ppt&ei=n3eGUseFHKyh4APFs4CgBQ&usg=AFQjCNGZtQsaGso-YaqLYSlOJaJfhDiaug&sig2=JzdEhA4q-4bhBDhE1NOxMQ&bvm=bv.56643336,d.dmg

2001: Sharp introducestheSL-5000 PDA running Linux

2002: Chris Larson finds out that the SharpROM sucks and starts hacking on a
build system for a customized Linux distribution called "OpenZaurus”

2002-2003: The OpenZaurus build system is getting stretched (beyond belief) by
adding support for many more packages and target devices

January 2003: Brainstorming towards a new distribution and device independent
build system

February 2003: Holger Schurig creates the OpenEmbedded repository and starts
hacking on the first version

May 2003: Chris Larson adds major functionality to the OpenEmbedded core and
starts converting packages from the OpenZaurus build system

December 2003: Michael Lauer releases OpenZaurus3.3.5, abandons the OpenZaurus
build system, and converts100s of packages to OpenEmbedded

December 2004: OpenEmbedded is split up into the BitBake build system and the
OpenEmbedded metadata

So the magic Dec 7 2004 date is the split of OpenEmbedded into bitbake and the
'metadata'.  the actual work was almost 20 months prior.

The sourceforge openembedded project was registerd 2003-01-21:

http://sourceforge.net/projects/openembedded/

Also I found a repository that appears it may contain the original
OpenEmbedded..  first commit is:

Author: Chris Larson 
Date:   Mon Jun 2 21:19:02 2003 +

  Initial repository create

  BKrev: 3edbbf46Zm7UJzG9iGisj7ELSsUuZQ


Never thought to look at the Bitbake repository.. first commit:

commit af645b03b585a9c92dc88756b8f6badfec5f
Author: Chris Larson 
Date:   Fri Feb 21 04:03:45 2003 +

 .oe file parser function

So I think that Jives with the Approx Feb 2003 timeframe..  and I'd say the code 
birthday then would be Feb 21 2003 -- so in 3 months we're looking at the 12th 
anniversary of Bitbake/OE.


--Mark




I know we've all forgotten the exact date :), but this is the best I
could find.

Philip








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

Re: [yocto] Happy Birthday, Yocto Project

[Mark Hatle]

On 11/14/13, 9:58 PM, Jeff Osier-Mixon wrote:

Hm, a day that will live in infamy indeed

On Fri, Nov 15, 2013 at 3:09 AM, Philip Balister  wrote:

On 11/14/2013 08:22 PM, Robert P. J. Day wrote:

On Thu, 14 Nov 2013, Jeff Osier-Mixon wrote:


Happy birthday, Yocto Project!


   what's a birthday without cake?

http://www.instructables.com/id/Brain-Cake/

rday



Berlios suggests bitbake was born on Dec 7, 2004. So in a few weeks we
will celebrate the 9'th birthday of the OpenEmbedded build system.


I found a presentation that seems to have a bit more history in it.

OpenEmbedded & BitBake - Denx.
www.denx.de/wiki/pub/ELDKHistory/.../OpenEmbeddedv1.ppt‎
December 2004: OpenEmbedded is split up into the BitBake build system and the 
OpenEmbedded metadata. OpenZaurus. OpenEmbedded is the successor to  ..


http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=6&ved=0CE0QFjAF&url=http%3A%2F%2Fwww.denx.de%2Fwiki%2Fpub%2FELDKHistory%2FDocumentationLinks%2FOpenEmbeddedv1.ppt&ei=n3eGUseFHKyh4APFs4CgBQ&usg=AFQjCNGZtQsaGso-YaqLYSlOJaJfhDiaug&sig2=JzdEhA4q-4bhBDhE1NOxMQ&bvm=bv.56643336,d.dmg

2001: Sharp introducestheSL-5000 PDA running Linux

2002: Chris Larson finds out that the SharpROM sucks and starts hacking on a 
build system for a customized Linux distribution called "OpenZaurus”


2002-2003: The OpenZaurus build system is getting stretched (beyond belief) by 
adding support for many more packages and target devices


January 2003: Brainstorming towards a new distribution and device independent 
build system


February 2003: Holger Schurig creates the OpenEmbedded repository and starts 
hacking on the first version


May 2003: Chris Larson adds major functionality to the OpenEmbedded core and 
starts converting packages from the OpenZaurus build system


December 2003: Michael Lauer releases OpenZaurus3.3.5, abandons the OpenZaurus 
build system, and converts100s of packages to OpenEmbedded


December 2004: OpenEmbedded is split up into the BitBake build system and the 
OpenEmbedded metadata


So the magic Dec 7 2004 date is the split of OpenEmbedded into bitbake and the 
'metadata'.  the actual work was almost 20 months prior.


The sourceforge openembedded project was registerd 2003-01-21:

http://sourceforge.net/projects/openembedded/

Also I found a repository that appears it may contain the original 
OpenEmbedded..  first commit is:


Author: Chris Larson 
Date:   Mon Jun 2 21:19:02 2003 +

Initial repository create

BKrev: 3edbbf46Zm7UJzG9iGisj7ELSsUuZQ



I know we've all forgotten the exact date :), but this is the best I
could find.

Philip






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

Re: [yocto] [meta-selinux][PATCH] policycoreutils: Patch Makefile to get load_policy symlink right.

[Mark Hatle]

On 1/9/14, 5:26 PM, fl...@twobit.us wrote:

From: Philip Tricca 

Setting DESTDIR in the policycoreutils do_install creates a bad
symlink for load_policy. This patch fixes up the Makefile to
create the symlink relative to DESTDIR.


Merged to 'master-next'.  Note, I updated the patch to include a copy of the 
commit message it indicate what the purpose of the patch was.



Signed-off-by: Philip Tricca 
---
  .../policycoreutils-loadpolicy-symlink.patch|   11 +++
  recipes-security/selinux/policycoreutils_2.1.14.bb  |1 +
  2 files changed, 12 insertions(+)
  create mode 100644 
recipes-security/selinux/policycoreutils/policycoreutils-loadpolicy-symlink.patch

diff --git 
a/recipes-security/selinux/policycoreutils/policycoreutils-loadpolicy-symlink.patch
 
b/recipes-security/selinux/policycoreutils/policycoreutils-loadpolicy-symlink.patch
new file mode 100644
index 000..e0bd352
--- /dev/null
+++ 
b/recipes-security/selinux/policycoreutils/policycoreutils-loadpolicy-symlink.patch
@@ -0,0 +1,11 @@
+--- a/load_policy/Makefile
 b/load_policy/Makefile
+@@ -19,7 +19,7 @@ install: all
+   test -d $(MANDIR)/man8 || install -m 755 -d $(MANDIR)/man8
+   install -m 644 load_policy.8 $(MANDIR)/man8/
+   -mkdir -p $(USRSBINDIR)
+-  -ln -sf $(SBINDIR)/load_policy $(USRSBINDIR)/load_policy
++  -ln -sf $(subst $(DESTDIR),,$(SBINDIR))/load_policy 
$(USRSBINDIR)/load_policy
+
+ clean:
+   -rm -f $(TARGETS) *.o
diff --git a/recipes-security/selinux/policycoreutils_2.1.14.bb 
b/recipes-security/selinux/policycoreutils_2.1.14.bb
index b177042..8a35322 100644
--- a/recipes-security/selinux/policycoreutils_2.1.14.bb
+++ b/recipes-security/selinux/policycoreutils_2.1.14.bb
@@ -12,4 +12,5 @@ SRC_URI += "\
file://policycoreutils-fix-strict-prototypes.patch \
file://policycoreutils-revert-run_init-open_init_pty.patch \
file://policycoreutils-fix-sepolicy-install-path.patch \
+   file://policycoreutils-loadpolicy-symlink.patch \
"



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

Re: [yocto] [meta-selinux][PATCH 00/10] selinux userspace: uprev packages to release 20131030

[Mark Hatle]

On 1/8/14, 7:38 PM, wenzong@windriver.com wrote:

merged to master-next


From: Wenzong Fan 

Changes:
1) Uprev selinux packages to release 20131030;
2) Fix build dependency to libsemanage;
3) Fix QA issues to policycoreutils;
4) Update LIC_FILES_CHKSUM for selinux packagegroups.

Some Tests:
1) build test:
- add meta-selinux path to conf/bblayers.conf;
- add DISTRO_FEATURES_append=" pam selinux" to conf/local.conf;
- build selinux image:
   $ bitbake core-image-selinux

- add below configs to conf/local.conf and run image build:
   PREFERRED_VERSION_checkpolicy = "2.2+gitAUTOINC+edc2e99687"
   PREFERRED_VERSION_libselinux = "2.2+gitAUTOINC+edc2e99687"
   PREFERRED_VERSION_libsemanage = "2.2+gitAUTOINC+edc2e99687"
   PREFERRED_VERSION_libsepol = "2.2+gitAUTOINC+edc2e99687"
   PREFERRED_VERSION_policycoreutils = "2.2.5+gitAUTOINC+edc2e99687"
   PREFERRED_VERSION_sepolgen = "1.2.1+gitAUTOINC+edc2e99687"

All builds successfully.

2) basic verification on target:
$ runqemu qemux86 core-image-selinux ext3 nographic qemuparams="-m 1024"

qemux86 login: root
root@qemux86:~# id -Z
root:sysadm_r:sysadm_t:s0-s15:c0.c1023

root@qemux86:~# sestatus
SELinux status: enabled
SELinuxfs mount:/sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: mls
Current mode:   enforcing
Mode from config file:  enforcing
Policy MLS status:  enabled
Policy deny_unknown status: allowed
Max kernel policy version:  28


The following changes since commit 2209cb5fc21c1ad5a7471897528ed64170f70219:

   policy: Create compressed_policy distro feature (2013-12-05 09:03:41 -0500)

are available in the git repository at:

   git://git.pokylinux.org/poky-contrib wenzong/selinux-uprev
   http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=wenzong/selinux-uprev

Wenzong Fan (10):
   selinux userspace: uprev packages to release 20131030
   checkpolicy: migrate SRC_URI to 2.2
   libselinux: migrate SRC_URI and patches to 2.2
   libsemanage: migrate SRC_URI to 2.2
   libsepol: migrate SRC_URI to 2.2
   policycoreutils: migrate SRC_URI and patches to 2.2.5
   sepolgen: migrate SRC_URI to 1.2.1
   libsemanage: add audit dependency
   policycoreutils: fix QA issues
   selinux packagegroups: update LIC_FILES_CHKSUM

  recipes-security/audit/audit_2.3.2.bb  |8 -
  .../packagegroups/packagegroup-core-selinux.bb |2 +-
  .../packagegroups/packagegroup-selinux-minimal.bb  |2 +-
  .../packagegroup-selinux-policycoreutils.bb|2 +-
  recipes-security/selinux/checkpolicy_2.1.12.bb |9 --
  recipes-security/selinux/checkpolicy_2.2.bb|9 ++
  recipes-security/selinux/checkpolicy_git.bb|2 +-
  .../libselinux-fix-init-load-policy.patch  |   27 
  .../libselinux/libselinux-pcre-link-order.patch|   31 --
  .../{libselinux_2.1.13.bb => libselinux_2.2.bb}|8 ++---
  recipes-security/selinux/libselinux_git.bb |   10 --
  recipes-security/selinux/libsemanage.inc   |2 +-
  .../libsemanage/libsemanage-fix-path-nologin.patch |9 +++---
  .../{libsemanage_2.1.10.bb => libsemanage_2.2.bb}  |6 ++--
  recipes-security/selinux/libsemanage_git.bb|3 +-
  recipes-security/selinux/libsepol.inc  |5 ++-
  ...ibsepol-Change-ranlib-for-cross-compiling.patch |   31 --
  recipes-security/selinux/libsepol_2.1.9.bb |   11 ---
  recipes-security/selinux/libsepol_2.2.bb   |9 ++
  recipes-security/selinux/libsepol_git.bb   |4 +--
  recipes-security/selinux/policycoreutils.inc   |   12 ---
  ...policycoreutils-fix-sepolicy-install-path.patch |   18 +--
  .../policycoreutils-fix-strict-prototypes.patch|   34 
  .../policycoreutils-make-O_CLOEXEC-optional.patch  |   28 
  ...oreutils_2.1.14.bb => policycoreutils_2.2.5.bb} |9 +++---
  recipes-security/selinux/policycoreutils_git.bb|8 +++--
  recipes-security/selinux/selinux_20130423.inc  |   12 ---
  recipes-security/selinux/selinux_20131030.inc  |   12 +++
  recipes-security/selinux/selinux_git.inc   |4 +--
  recipes-security/selinux/sepolgen_1.1.9.bb |9 --
  recipes-security/selinux/sepolgen_1.2.1.bb |9 ++
  recipes-security/selinux/sepolgen_git.bb   |2 +-
  32 files changed, 117 insertions(+), 230 deletions(-)
  delete mode 100644 recipes-security/selinux/checkpolicy_2.1.12.bb
  create mode 100644 recipes-security/selinux/checkpolicy_2.2.bb
  delete mode 100644 
recipes-security/selinux/libselinux/libselinux-fix-init-load-policy.patch
  delete mode 100644 
recipes-security/selinux/libselinux/libselinux-pcre-link-order.patch
  rename recipes-security/selinux/{libselinux_2.1.13.bb => libselinux_2.2.bb} 
(58%)
  rename recipes-security/selinux/{libsem

Re: [yocto] [meta-selinux][PATCH 0/1] refpolicy: fix real path for udevd

[Mark Hatle]

merged to master-next

On 1/8/14, 8:54 PM, wenzong@windriver.com wrote:

From: Wenzong Fan 

In Yocto the real path for udevd is /lib/udev/udevd, this patch fixes
the init issues like:

 udevd[87]: setfilecon /dev/vcsa2 failed: Operation not permitted
 udevd[89]: setfilecon /dev/fb0 failed: Operation not permitted

The following changes since commit 2209cb5fc21c1ad5a7471897528ed64170f70219:

   policy: Create compressed_policy distro feature (2013-12-05 09:03:41 -0500)

are available in the git repository at:

   git://git.pokylinux.org/poky-contrib wenzong/fix-udevd-path
   http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=wenzong/fix-udevd-path

Wenzong Fan (1):
   refpolicy: fix real path for udevd

  .../refpolicy-2.20130424/poky-fc-udevd.patch   |   27 
  .../refpolicy/refpolicy_2.20130424.inc |1 +
  2 files changed, 28 insertions(+)
  create mode 100644 
recipes-security/refpolicy/refpolicy-2.20130424/poky-fc-udevd.patch



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

[yocto] [meta-selinux] master & dora updated

[Mark Hatle]

master and dora branches have been updated.

If anyone finds any issues, please let Pascal and I know.

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

Re: [yocto] Smart - "Illegal instruction"

[Mark Hatle]

On 1/24/14, 4:26 AM, Burton, Ross wrote:

On 24 January 2014 10:21,   wrote:

Do I have to define a new BSP?

Did anyone have a similar problem and could give me some advice?


IIRC, genericx86 targets Atom and higher (the README lists the target
hardware) so it's quite possible that the compiler is emitting
instructions that your CPU doesn't actually have.  You could create a
new BSP, or edit the tune flags from your distro or local
configuration to target your CPU.


I believe that this AMD Sempron processor is using an older instruction set.  So 
as Ross indicated, the best approach is to define a correct tune and BSP for 
your part.


Looking at what I found online, it appears the Sempron 2100 supports:

MMX, 3DNow!, SSE, SSE2, SSE3, AMD64 and EVP

The atom tune is compatible with the core2 tune.  The core2 supports

MMX, SSE, SSE2, SSE3, SSE4.1, and Supplemental SSE3

So my guess is that last two items is the issue.  If you copy the genericx86 BSP 
and modify the configuration to use the tune-x86_64.inc instead, that may fix 
your issue.


--Mark


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



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

[yocto] [meta-selinux][PATCH] audit: Fix lack of a default audit.rules

[Mark Hatle]

Various components were failing, and upon investigation it was noted
that the audit.rules file referenced by the initscript wasn't available.

There was however a copy under the rules.d directory.  Investigating
the audit.spec file (which in the upstream source) showed that it was
expected that the version in the rules.d should be copied into
/etc/audit.

Do this and correct the systemd services file to use the same file.

Signed-off-by: Mark Hatle 
---
 recipes-security/audit/audit/auditd.service | 2 +-
 recipes-security/audit/audit_2.3.2.bb   | 5 +
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/recipes-security/audit/audit/auditd.service 
b/recipes-security/audit/audit/auditd.service
index 6daa056..adf4d3b 100644
--- a/recipes-security/audit/audit/auditd.service
+++ b/recipes-security/audit/audit/auditd.service
@@ -14,7 +14,7 @@ ExecStart=/sbin/auditd -n
 ## Then copy existing rules to /etc/audit/rules.d/
 ## Not doing this last step can cause loss of existing rules
 #ExecStartPost=-/sbin/augenrules --load
-ExecStartPost=-/sbin/auditctl -R /etc/audit/rules.d/audit.rules
+ExecStartPost=-/sbin/auditctl -R /etc/audit/audit.rules
 ExecReload=/bin/kill -HUP $MAINPID
 
 [Install]
diff --git a/recipes-security/audit/audit_2.3.2.bb 
b/recipes-security/audit/audit_2.3.2.bb
index 4a9c954..ae6556f 100644
--- a/recipes-security/audit/audit_2.3.2.bb
+++ b/recipes-security/audit/audit_2.3.2.bb
@@ -67,6 +67,8 @@ FILES_${PN}-dbg += 
"${libdir}/python${PYTHON_BASEVERSION}/*/.debug"
 FILES_${PN}-python = "${libdir}/python${PYTHON_BASEVERSION}"
 FILES_${PN}-dev += "${base_libdir}/*.so ${base_libdir}/*.la"
 
+CONFFILES_auditd += "${sysconfdir}/audit/audit.rules"
+
 do_install_append() {
rm -f ${D}/${libdir}/python${PYTHON_BASEVERSION}/site-packages/*.a
rm -f ${D}/${libdir}/python${PYTHON_BASEVERSION}/site-packages/*.la
@@ -91,4 +93,7 @@ do_install_append() {
 
chmod 750 ${D}/etc/audit ${D}/etc/audit/rules.d
chmod 640 ${D}/etc/audit/auditd.conf ${D}/etc/audit/rules.d/audit.rules
+
+   # Based on the audit.spec "Copy default rules into place on new 
installation"
+   cp ${D}/etc/audit/rules.d/audit.rules ${D}/etc/audit/audit.rules
 }
-- 
1.8.5.3

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

Re: [yocto] Question about rebuilding RPM package index for updated RPMs when bitbake completes

[Mark Hatle]

On 4/20/14, 7:15 AM, Alex J Lennon wrote:

Hi,

I'm trying to put in place a development workflow using the PR server,
RPM package feeds and smart update/install on a target.

I see that when I modify and rebuild my recipe, foo, the PR server
increments its count within the RPM filename, but the RPM feed data
doesn't seem to update.



...


So if I am understanding the above correctly, when I make a change to a
recipe and build it, PR automatically
updates, the old RPM is removed and the new RPM added to the feed
directory. However the package index
for the feed is not updated.

So if at that point I try to make use of the feed on a target I am
likely to find something is broken.


The feed is normally indexed (createrepo) either when you manually run the 
package-index operation, or when you construct a filesystem.  Until you do that, 
the feed directories are transient.



If that is true would it make sense to leave the old RPM in the feed
directory until package-index
is re-ran, or to run package-index automatically at the end of a build
when RPMs have changed?


I -never- export the feed directories from the project directory.  Instead, I 
copy the packages from the feed directory to where I share them, and then run 
the indexer against the external repository.  This preserves the older versions 
and also makes the new ones available.


To run the indexer I have to configure and run it manually...

PATH=/home/mhatle/build-6.0-RCPL-test/build/tmp/sysroots/x86_64-linux/bin:/home/mhatle/build-6.0-RCPL-test/bitbake/tmp/sysroots/x86_64-linux/usr/bin:$PATH
/home/mhatle/build-6.0-RCPL-test/bitbake/tmp/sysroots/x86_64-linux/usr/bin/createrepo 
--update -q 


So for qemux86_64, I end up running the above three times.  all, x86_64 and 
qemux86_64.


Then on the target I just do:

smart update
smart upgrade -y

--Mark


Thanks,

Alex





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

Re: [yocto] Question about rebuilding RPM package index for updated RPMs when bitbake completes

[Mark Hatle]

On 4/22/14, 1:50 AM, Alex J Lennon wrote:


On 22/04/2014 02:36, Mark Hatle wrote:

On 4/20/14, 7:15 AM, Alex J Lennon wrote:

Hi,

I'm trying to put in place a development workflow using the PR server,
RPM package feeds and smart update/install on a target.

I see that when I modify and rebuild my recipe, foo, the PR server
increments its count within the RPM filename, but the RPM feed data
doesn't seem to update.



...


So if I am understanding the above correctly, when I make a change to a
recipe and build it, PR automatically
updates, the old RPM is removed and the new RPM added to the feed
directory. However the package index
for the feed is not updated.

So if at that point I try to make use of the feed on a target I am
likely to find something is broken.


The feed is normally indexed (createrepo) either when you manually run the
package-index operation, or when you construct a filesystem.  Until you do
that, the feed directories are transient.



Is there a reason for this? Surely having a package index that is out of sync
with the packages until a manual operation is performed isn't ideal?


Yes, if you re-indexed the set of packages after each package, you will add 
multiple minutes to the construction of each package, and introduce locking into 
the system.  (You won't be able to generate multiple recipes in parallel due to 
this.)  (I don't consider it a package feed until all of the packages are built 
and the index is constructed.)



If that is true would it make sense to leave the old RPM in the feed
directory until package-index
is re-ran, or to run package-index automatically at the end of a build
when RPMs have changed?


I -never- export the feed directories from the project directory. Instead, I
copy the packages from the feed directory to where I share them, and then run
the indexer against the external repository.  This preserves the older
versions and also makes the new ones available.

To run the indexer I have to configure and run it manually...

PATH=/home/mhatle/build-6.0-RCPL-test/build/tmp/sysroots/x86_64-linux/bin:/home/mhatle/build-6.0-RCPL-test/bitbake/tmp/sysroots/x86_64-linux/usr/bin:$PATH

/home/mhatle/build-6.0-RCPL-test/bitbake/tmp/sysroots/x86_64-linux/usr/bin/createrepo
--update -q 

So for qemux86_64, I end up running the above three times.  all, x86_64 and
qemux86_64.

Then on the target I just do:

smart update
smart upgrade -y



Thanks, that's useful

However I still believe the core question stands, which is why the package index
is out of sync, and why it's a good thing to have to run bitbake package-index


The other option is to remove the repo indexes when packages are written. 
Again, I don't consider these out of sync though, as the files have different 
purposes and constraints.  They are simply constructed to enable the rootfs 
generation.  Upgrades are external of the build system.



manually to bring the package index back into sync with the packages?

I too export the feed directories to a server for 3rd party consumption via
compressed rsync over SSH. I don't want to expose more on the server than a
simple SSH endpoint, and rsync seems a sensible way to minimise copying times,
so either I need the package index to be correct prior to the rsync, I need to
export, say, an NFS filesystem which I don't want to do, or I need some
createrepo specifics on what I would prefer to be a dumb web-server.


For an rsync, I would either index on the server using a cron-job.. so when new 
packages appear they get added to the index, or have a local mirror of the 
directory including the updated index... you just want to make sure the index 
files are synced last somehow.


--Mark


Best,

Alex


--Mark


Thanks,

Alex







--

Dynamic Devices Ltd <http://www.dynamicdevices.co.uk/>

Alex J Lennon / Director
1 Queensway, Liverpool L22 4RA

mobile: +44 (0)7956 668178

Linkedin <http://www.linkedin.com/in/alexjlennon> Skype 

This e-mail message may contain confidential or legally privileged information
and is intended only for the use of the intended recipient(s). Any unauthorized
disclosure, dissemination, distribution, copying or the taking of any action in
reliance on the information herein is prohibited. E-mails are not secure and
cannot be guaranteed to be error free as they can be intercepted, amended, or
contain viruses. Anyone who communicates with us by e-mail is deemed to have
accepted these risks. Company Name is not responsible for errors or omissions in
this message and denies any responsibility for any damage arising from the use
of e-mail. Any opinion and other statement contained in this message and any
attachment are solely those of the author and do not necessarily represent those
of the company.



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

Re: [yocto] Installation order question with RPM backend

[Mark Hatle]

On 4/11/12 10:14 AM, Xu, Dongxiao wrote:

Hi Mark,

I met a strange issue while using RPM to generate the rootfs.

In the installation list, if we have 2 RPM packages, say A.rpm and
B.rpm. package A RDEPENDS on package B. While installing the two
packages? Does RPM ensures to install B first and then install A?

The real issue is: we have certain packages that need to run
useradd/groupadd at rootfs time, for example, the dbus. However the
useradd/groupadd bbclass RDEPENDS on base-files, which provides
the /etc/group file. While installing the final image, sometimes we saw
it installs dbus firstly and then base-files, causing the
useradd/groupadd script error since it could not find /etc/group file.


it does enforce install order, however the /etc/group, /etc/passwd files (last 
time I checked) were being put into place by the post install scripts.  The 
scripting order is handled somewhat independently of the package install order. 
 (post install scripts get delayed intentionally for performance reasons. 
There is a way to hint a dependency for them as well...)


The passwd/group files are fairly unique files, and generally are installed 
-first- (individually) before any other packages on most RPM installations. 
After that the methods and install ordering works...


--Mark


I tried ipk and it doesn't have problem since it ensures to install
base-files firstly.

Any comment is welcome.

Thanks,
Dongxiao



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

Re: [yocto] Installation order question with RPM backend

[Mark Hatle]

On 4/11/12 10:37 AM, Xu, Dongxiao wrote:

On Wed, 2012-04-11 at 10:25 -0500, Mark Hatle wrote:

On 4/11/12 10:14 AM, Xu, Dongxiao wrote:

Hi Mark,

I met a strange issue while using RPM to generate the rootfs.

In the installation list, if we have 2 RPM packages, say A.rpm and
B.rpm. package A RDEPENDS on package B. While installing the two
packages? Does RPM ensures to install B first and then install A?

The real issue is: we have certain packages that need to run
useradd/groupadd at rootfs time, for example, the dbus. However the
useradd/groupadd bbclass RDEPENDS on base-files, which provides
the /etc/group file. While installing the final image, sometimes we saw
it installs dbus firstly and then base-files, causing the
useradd/groupadd script error since it could not find /etc/group file.


it does enforce install order, however the /etc/group, /etc/passwd files (last
time I checked) were being put into place by the post install scripts.  The
scripting order is handled somewhat independently of the package install order.
   (post install scripts get delayed intentionally for performance reasons.
There is a way to hint a dependency for them as well...)

The passwd/group files are fairly unique files, and generally are installed
-first- (individually) before any other packages on most RPM installations.
After that the methods and install ordering works...


But does the following log indicates the dbus-1 is installed before
base-passwd?

dbus-1##
  Adding system startup
for 
/distro/sdb/build-basic/tmp/work/qemux86-poky-linux/hob-image-hob-basic-1.0-r0/rootfs/etc/init.d/dbus-1.
kernel-module-uvesafb ##
libusb-compat ##
base-passwd   ##


Certainly appears that way.. but we'd need to look into the packages and 
understand the requirements as they are defined and trace them to see if there 
is a problem w/ the ordering or if the packages have a problem.


You will often see mysterious reordering when there is a circular dependency. 
RPM has to break this dependency in some way, and it does it by simply choosing 
one or the other.  (There is a hint mechanism for circular dependencies, but 
we've never used it.)


My suggestion is lets look at the package runtime dependenices and manually 
trace them..  Focus on dbus-1 and base-passwd... and see if the order is right 
or wrong or if there is a circular dependency.


(Also our version of RPM 5 is a bit old, and there are some known bugs in it.. 
as far as I know, none of them with the dependency resolution or code paths we 
follow.)


--Mark


Thanks,
Dongxiao


--Mark


I tried ipk and it doesn't have problem since it ensures to install
base-files firstly.

Any comment is welcome.

Thanks,
Dongxiao








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

Re: [yocto] Installation order question with RPM backend

[Mark Hatle]

On 4/11/12 10:51 AM, Xu, Dongxiao wrote:

On Wed, 2012-04-11 at 10:45 -0500, Mark Hatle wrote:

On 4/11/12 10:37 AM, Xu, Dongxiao wrote:

On Wed, 2012-04-11 at 10:25 -0500, Mark Hatle wrote:

On 4/11/12 10:14 AM, Xu, Dongxiao wrote:

Hi Mark,

I met a strange issue while using RPM to generate the rootfs.

In the installation list, if we have 2 RPM packages, say A.rpm and
B.rpm. package A RDEPENDS on package B. While installing the two
packages? Does RPM ensures to install B first and then install A?

The real issue is: we have certain packages that need to run
useradd/groupadd at rootfs time, for example, the dbus. However the
useradd/groupadd bbclass RDEPENDS on base-files, which provides
the /etc/group file. While installing the final image, sometimes we saw
it installs dbus firstly and then base-files, causing the
useradd/groupadd script error since it could not find /etc/group file.


it does enforce install order, however the /etc/group, /etc/passwd files (last
time I checked) were being put into place by the post install scripts.  The
scripting order is handled somewhat independently of the package install order.
(post install scripts get delayed intentionally for performance reasons.
There is a way to hint a dependency for them as well...)

The passwd/group files are fairly unique files, and generally are installed
-first- (individually) before any other packages on most RPM installations.
After that the methods and install ordering works...


But does the following log indicates the dbus-1 is installed before
base-passwd?

dbus-1##
   Adding system startup
for 
/distro/sdb/build-basic/tmp/work/qemux86-poky-linux/hob-image-hob-basic-1.0-r0/rootfs/etc/init.d/dbus-1.
kernel-module-uvesafb ##
libusb-compat ##
base-passwd   ##


Certainly appears that way.. but we'd need to look into the packages and
understand the requirements as they are defined and trace them to see if there
is a problem w/ the ordering or if the packages have a problem.

You will often see mysterious reordering when there is a circular dependency.
RPM has to break this dependency in some way, and it does it by simply choosing
one or the other.  (There is a hint mechanism for circular dependencies, but
we've never used it.)

My suggestion is lets look at the package runtime dependenices and manually
trace them..  Focus on dbus-1 and base-passwd... and see if the order is right
or wrong or if there is a circular dependency.


I checked the dbus.spec and base-passwd.spec.
For dbus.spec, there is a line:

%package -n dbus-1
Requires: base-passwd

And for base-passwd, there is no dbus exists in base-passwd.spec.


You need to query the binary packages for the real values..

rpm -qp  --requires

(and --provides will show what it provides..)  then match those two up.. If you 
still don't come across some type of circular dependency, then let me know.. 
I'll start investigating further. (there is additional dependency resolution 
debugging I can enable, but it's difficult to explain how to interpret the tons 
of lines..)


--Mark


Thanks,
Dongxiao



(Also our version of RPM 5 is a bit old, and there are some known bugs in it..
as far as I know, none of them with the dependency resolution or code paths we
follow.)

--Mark


Thanks,
Dongxiao


--Mark


I tried ipk and it doesn't have problem since it ensures to install
base-files firstly.

Any comment is welcome.

Thanks,
Dongxiao













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

Re: [yocto] [PATCH 1/1] poky-tiny: fix eglibc configuration

[Mark Hatle]

On 4/16/12 5:14 PM, nitin.a.kam...@intel.com wrote:

From: Nitin A Kamble

eglibc needs libc-posix-regexp-glibc&  libc-libm-big enabled in it's
configuration to avoid following eglibc build issue.

...
| In file included from xregex.c:634:0:
| xregex.c: In function 'byte_regex_compile':
| xregex.c:3395:8: error: too few arguments to function 'findidx'
| ../locale/weight.h:23:1: note: declared here
...


If glibc is failing to build because of the above, you need to report the 
failure to the eglibc mailing list.


eglibc is expected to build with those items disabled.

If it's another package, then it would be nice to know which item it is, as 
there may be a workaround.. (coreutils for instance has the ability to provide 
an internal regex function...)


--Mark


This fixes bug [YOCTO #2295]

Signed-off-by: Nitin A Kamble
---
  meta-yocto/conf/distro/poky-tiny.conf |4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta-yocto/conf/distro/poky-tiny.conf 
b/meta-yocto/conf/distro/poky-tiny.conf
index 58d64ec..626b2d0 100644
--- a/meta-yocto/conf/distro/poky-tiny.conf
+++ b/meta-yocto/conf/distro/poky-tiny.conf
@@ -62,7 +62,7 @@ ASSUME_PROVIDED += "pkgconfig$"

  # Reconfigure eglibc for a smaller installation
  # Comment out any of the lines below to disable them in the build
-DISTRO_FEATURES_LIBC_TINY = "libc-libm libc-crypt"
+DISTRO_FEATURES_LIBC_TINY = "libc-libm libc-libm-big libc-crypt"
  # for gettext
  DISTRO_FEATURES_LIBC_TINY += "libc-posix-clang-wchar"
  # for m4
@@ -71,7 +71,7 @@ DISTRO_FEATURES_LIBC_TINY += "libc-spawn libc-locale-code"
  DISTRO_FEATURES_LIBC_TINY += "libc-ftraverse"
  # Required for "who"
  DISTRO_FEATURES_LIBC_MINIMAL = "libc-utmp libc-getlogin"
-DISTRO_FEATURES_LIBC_REGEX = "libc-posix-regexp"
+DISTRO_FEATURES_LIBC_REGEX = "libc-posix-regexp libc-posix-regexp-glibc"
  DISTRO_FEATURES_LIBC_NET = "libc-inet libc-nis"

  DISTRO_FEATURES_LIBC = "${DISTRO_FEATURES_LIBC_TINY} \


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

Re: [yocto] A question about PACKAGE_ARCH renaming

[Mark Hatle]

On 4/16/12 8:01 PM, Xu, Dongxiao wrote:

Hi,

I am testing beagleboard with RPM, and there is a question I am confused
with that PACKAGE_ARCH is renamed for certain packages. For example the
"acl" package, whose expected PACKAGE_ARCH is "armv7a-vfp-neon", however
in RPM file, the arch is renamed to "armv7a", see
"acl-2.2.51-r2.armv7a.rpm". However IPK package still shows
"acl_2.2.51-r2_armv7a-vfp-neon.ipk".

Could anybody give hint on this?

Thanks,
Dongxiao



I've not seen that happen before.  Can you checked if an 
acl-...armv7a-vfp-neon.rpm was generated and RPM is simply not using it, or was 
it never generated?


As another user mentioned, it is possible for a package to say it wants a 
specific arch type, but if it did -- it should be consistent between packaging 
systems.


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

Re: [yocto] A question about PACKAGE_ARCH renaming

[Mark Hatle]

On 4/17/12 1:43 AM, Samuel Stirtzel wrote:

2012/4/17 Xu, Dongxiao:

Hi,

I am testing beagleboard with RPM, and there is a question I am confused
with that PACKAGE_ARCH is renamed for certain packages. For example the
"acl" package, whose expected PACKAGE_ARCH is "armv7a-vfp-neon", however
in RPM file, the arch is renamed to "armv7a", see
"acl-2.2.51-r2.armv7a.rpm". However IPK package still shows
"acl_2.2.51-r2_armv7a-vfp-neon.ipk".

Could anybody give hint on this?


Hi,
if applications need to be machine / hardware specific they can
indicate so by setting PACKAGE_ARCH.

For example I use it for recipes that build different when other
machine dependent packages are used by them:
kde-workspace can use the OpenGL ES driver which is machine dependent
so if it is used I set PACKAGE_ARCH = "${MACHINE_ARCH}".

AFAIK the vfp-neon arch indicates that the package uses hard float (or
"vector floating point") libraries instead of soft float.
See mfloat-abi at http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html


Just want to clarify...

VFP indicates it's using the VFP hardware for floating point, but the ABI 
remains as the standard EABI.  (adding 'hf' means that it's using the 
EABI-hardware floating point ABI instead.  Original EABI is defined to allow 
multiple instruction sets, processor units, etc to interact with a compatible 
ABI.  While EABI-hf requires vfp support.)


--Mark



Thanks,
Dongxiao

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






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