Re: [yocto] [PATCH resend][opkg-utils] opkg.py/opkg-build: fix creation of tar archives

[Tomas Frydrych]

On 24/10/12 12:14, Richard Purdie wrote:
> On Wed, 2012-10-24 at 12:53 +0200, Steffen Sledz wrote:
>> Since openSUSE 12.2 the installed tar uses posix instead of gnu encoding
>> by default. This format is not fully supported by opkg and results in
>> ipk packages not installable at the target.
>>
>> Collected errors:
>>  * get_header_tar: Unknown typeflag: 0x78: Success.
>>  * get_header_tar: Unknown typeflag: 0x78: Success.
>>  * get_header_tar: Unknown typeflag: 0x78: Success.
>>  * extract_archive: Don't know how to handle 
>> /var/lib/opkg/tmp/opkg-mg997m/chicken-bin-fGRvr4/PaxHeaders.17512/.: No such 
>> file or directory.
>>  * get_header_tar: Unknown typeflag: 0x78: No such file or directory.
>>  * get_header_tar: Unknown typeflag: 0x78: No such file or directory.
>>  ...
>>
>> Signed-off-by: Steffen Sledz 
>> ---
>>  opkg-build |6 +++---
>>  opkg.py|6 +++---
>>  2 files changed, 6 insertions(+), 6 deletions(-)
> 
> Merged to master, thanks.

Could this be also applied to the danny branch (and perhaps even denzil)?

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

Re: [yocto] Problem compiling diffutils on poky-tiny in danny

[Tomas Frydrych]

Hi Tim,

On 14/11/12 01:11, Tim Bird wrote:
> ./wctype.h:448:1: error: static declaration of 'iswalnum' follows non-static 
> declaration
> ./wctype.h:460:1: error: static declaration of 'iswalpha' follows non-static 
> declaration
> ...
> Has anyone seen this type of error before, or can provide some
> hints of what to check or adjust to fix this?

The diffutils package provides a replacement for wctypes.h, which
includes the system wctypes.h and then adds some stuff of it's own -- I
think you are hitting the '#if !GNULIB_defined_wctype_functions' in the
replacement file, which expects to be providing iswalnum, etc., and
prototypes them as 'static inline'; the system wctypes.h protypes are
not static.

Not sure why it should be taking that path, could be because these
functions are not provided by libc for poky-tiny (in which case the libc
headers need patching), or could be the detection in diffutils is
broken. As a quick hack, try removing the offending prototypes from the
sysroot wctypes.h.

Tomas

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

Re: [yocto] Use of BBPATH in a layer.conf file.

[Tomas Frydrych]

On 02/12/12 22:51, Scott Garman wrote:
> Robert Day has brought up an inconsistency in the way we append to
> BBPATH within a couple of our layer.conf files.
> 
> In meta-hob, meta-yocto-bsp, and meta-intel, we do:
> 
> BBPATH := "${BBPATH}:${LAYERDIR}"
> 
> but in meta-yocto, we do:
> 
> BBPATH := "${LAYERDIR}:${BBPATH}"
> 
> Unless someone explains to me that it's necessary to use this different
> ordering in meta-yocto's layer.conf, I will submit a patch to make this
> more consistent.

This meta-yocto setup is intentional (there was thread about that a
while back). meta-yocto is a distro layer, and for any distro layer it
is reasonable to enforce its own precedence over any other layers is may
use, and meta-yocto chooses to do this. Non-distro layers, including all
bsp layers, are expected to always use an append operation so that they
can be stacked together.

Tomas

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

Re: [yocto] Set hostname on image?

[Tomas Frydrych]

On 21/12/12 15:04, Jonas Jonsson L wrote:
> The installed (/etc/hostname) file is created & installed in the
> base-files recipe, but I don't understand how to set/use the
> hostname-variable in that recipe so that it becomes what I want it to be
> (unless I start editing that recipe ).
>  
> Is there a way to modify the hostname from my 'local.conf' file?

You will not be able to override it in local.conf because the 'hostname'
variable in the recipe is not weakly assigned. But you should be able to
override it in a base-files.bbappend.

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

Re: [yocto] I think my kernel image just went back in time...

[Tomas Frydrych]

On 09/12/12 23:17, Chris Tapp wrote:
> In tmp/deploy/images:
> 
> 1) bzImage had a timestamp of 2012-12-09 21:49 and the file ended
> -20121209214459.bin
> 
> 2) Cleaned the image and the task it contained (to pick up some
> changes on rebuild) and deleted the image files (.hddimg, etc.) in
> tmp/deploy/images making sure to leave the kernel files intact.

Did you cleansstate it? I find that without cleaning the state kernel
image gets always pulled out of sstate rather than properly rebuilt.

Tomas



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

Re: [yocto] [meta-raspberrypi][PATCH 2/2] Add RPROVIDES for OpenGL libraries

[Tomas Frydrych]

On 30/01/13 21:51, Philipp Wagner wrote:
> https://github.com/djwillis/meta-raspberrypi/issues/55
>
>  PROVIDES = "virtual/libgl virtual/libgles2 virtual/egl"
> +RPROVIDES = "virtual/libgl virtual/libgles2 virtual/egl"

As I noted in the above issue, this really is wrong; there is *no* libgl
provided by the RPi firmware.

Tomas


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

Re: [yocto] Matchbox keyboard

[Tomas Frydrych]

On 05/02/13 18:47, Gary Thomas wrote:
> Sorry if this isn't the best place to ask...
> 
> I have a GUI application running on Poky/Yocto with Sato using
> only a touch screen.  My application window takes up the whole
> display which is *very* small (320x240).  If I try and accept
> text input, I can see the matchbox keyboard try to pop up, but
> it immediately ends up behind my application window and thus
> is of little use :-(

This should not be too small, I am pretty sure I have used it on a
device of that size, but it assumes the GUI application is well behaved
and obeys the window manager -- you have to make it respect the size the
WM allocates.

Tomas

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

Re: [yocto] Matchbox keyboard

[Tomas Frydrych]

On 05/02/13 19:19, Gary Thomas wrote:
> On 2013-02-05 12:00, Tomas Frydrych wrote:
>> On 05/02/13 18:47, Gary Thomas wrote:
>>> Sorry if this isn't the best place to ask...
>>>
>>> I have a GUI application running on Poky/Yocto with Sato using
>>> only a touch screen.  My application window takes up the whole
>>> display which is *very* small (320x240).  If I try and accept
>>> text input, I can see the matchbox keyboard try to pop up, but
>>> it immediately ends up behind my application window and thus
>>> is of little use :-(
>>
>> This should not be too small, I am pretty sure I have used it on a
>> device of that size, but it assumes the GUI application is well behaved
>> and obeys the window manager -- you have to make it respect the size the
>> WM allocates.
> 
> Does the window manager attempt to resize my window when the keyboard
> pops up?  I have a simple dialog and I don't see it being resized (if
> that's even possible)

In the matchbox case it works through the window stack and works out the
size that is taken up by DOCKS and TOOLBARS (the kbd is a toolbar,
iirc); whatever is left is then given to the other windows (applications
and dialogs). Simplest way to verify if the WM is trying to resize the
dialog is to listen for the ConfigureNotify event and see what sizes are
coming through there (how you do that would depend on the toolkit).

Tomas

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

Re: [yocto] pulseaudio madness

[Tomas Frydrych]

On 06/02/13 13:50, Gary Thomas wrote:
> On 2013-02-05 06:52, Burton, Ross wrote:
>> Hi Gary,
>>
>> On 5 February 2013 12:44, Gary Thomas  wrote:
>>> I have a multi-media application/system (built with Poky/Yocto of
>>> course)
>>> that is currently using ALSA for the sound.  This works great but now
>>> I'd like to be able to share some of the sound resources, in particular
>>> the audio output (speakers).  To satisfy this, I looked at pulseaudio,
>>> but I'm overwhelmed by the package choices (there are 120 packages),
>>> not to mention what to do about configuration.
>>>
>>> I don't see any examples (images, etc) that use pulseaudio.
>>>
>>> Does anyone have any recommendations on what I might need to install,
>>> how to configure it, etc, to take over from my simple ALSA setup?
>>
>> The top tip is the PulseAudio documentation on the web site, that
>> lists all the plugins and what they do.  The pulseaudio-server package
>> depends on all of the important plugins, so that gives you a working
>> PA setup once you've started it.
>>
>> You might want to have a look at Guacamayo's use of PA, that uses it
>> and will automatically switch output when new speakers are plugged in
>> too.https://github.com/Guacamayo
> 
> Thanks, that helped.  I've built Guacamayo for my RaspberryPi and
> can see how it's set up.
> 
> One thing I'm missing is how the pulseaudio server gets started?

Depends on the image type, either from /eta/xdg/autostart, or for the
audiplayer image from the /etc/init.d/guacamayo-session-* script.

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

Re: [yocto] Running Sato/X11 as non-root

[Tomas Frydrych]

On 06/02/13 14:40, Gary Thomas wrote:
> In my attempt to get pulseaudio running, I need to bring up
> my X11 session with a user that is not root.  The default
> (core-image-sato) always starts X11 as root.  This yields
> these errors when starting (with pulseaudio installed):
>   W: [pulseaudio] main.c: This program is not intended to be run as root
> (unless --system is specified).
>   E: [autospawn] core-util.c: Home directory /home/root not ours.
>   W: [autospawn] lock-autospawn.c: Cannot access autospawn lock.
>   E: [pulseaudio] main.c: Failed to acquire autospawn lock
>   W: [pulseaudio] main.c: This program is not intended to be run as root
> (unless --system is specified).
>   E: [autospawn] core-util.c: Home directory /home/root not ours.
>   W: [autospawn] lock-autospawn.c: Cannot access autospawn lock.
>   E: [pulseaudio] main.c: Failed to acquire autospawn lock
> 
> So, I tried to make X run as user 'demo', which I created, by
> putting 'demo' in /etc/X11/Xusername.  Now it seems to try
> and run as 'demo', but falls over quite quickly:
>   Fatal server error:
>   [2951371.651] xf86OpenConsole: Cannot open /dev/tty0 (No such file or
> directory)
>   [2951371.651]
>   [2951371.651] (EE)
>   Please consult the The X.Org Foundation support
>  at http://wiki.x.org for help.
>   [2951371.651] (EE) Please also check the log file at
> "/var/log/Xorg.0.log" for additional information.
>   [2951371.651] (EE)
>   [2951371.652] (WW) xf86CloseConsole: KDSETMODE failed: Bad file
> descriptor
>   [2951371.652] (WW) xf86CloseConsole: VT_GETMODE failed: Bad file
> descriptor
>   [2951371.652] Server terminated with error (1). Closing log file.
> 
> Any ideas how I get this going?
> 
> n.b. not only do I want to get this going for myself, but I think
> the discussion (and maybe subsequent documentation) is useful since
> this functionality is in OE-core (or is it only Poky/Yocto - hard
> to tell)...

The user that the rootless X in Poky is expecting is called xuser; if
you use your own, you need to make sure that it's in all the appropriate
groups the server needs it to be in, etc.; see the xserver-nodm-init recipe.

Tomas

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

Re: [yocto] [meta-raspberrypi][PATCH 0/2] Binary graphics library fixes

[Tomas Frydrych]

Hi Andrei,

On 07/02/13 14:26, Andrei Gherzan wrote:
> We are moving to userland repo. So we will build our libraries

I tried to use the userland repo about a week ago and had to revert back
to using the binary firmware; the userland tree seem to miss some bcm
headers, so it was impossible to build apps against the libs whose
includes require those.

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

Re: [yocto] pulseaudio madness

[Tomas Frydrych]

On 06/02/13 22:43, Gary Thomas wrote:
>>> You might want to have a look at Guacamayo's use of PA, that uses it
>>> and will automatically switch output when new speakers are plugged in
>>> too.https://github.com/Guacamayo
>>
>> Thanks, that helped.  I've built Guacamayo for my RaspberryPi and
>> can see how it's set up.
> 
> That said, I've not had much luck actually getting anything out of the
> audio :-(  I tried the guacamayo-image-mex-raspberrypi.rpi-sdimg which
> came up and gave me a nice display but it wasn't obvious how to import
> media and/or make it play.  I tried copying some files manually to the
> SD card, but they wouldn't play either.

Both the guacamayo mex and audioplayer images are for UPnP appliances,
i.e., they generally expect to find content on the network, provided by
UPnP media servers (i.e., a NAS).

The mex image is not really much use on the RPi, the HW is too
underpowered to run a non-trivial GL application. But you can put the
audio files into the xuser's Music directory (or with the demo files
into /usr/share/demos/audio) and they should appear in the Music column
of MEX.


> Then I tried guacamayo-image-audioplayer-raspberrypi.rpi-sdimg and it
> was even less intuitive.

You need a UPnP media controller to interact with the audioplayer.
BubbleUPnP for Android works very well.


> Can you give me some guidance?  All I'd like to do is play a simple
> (.wav) file on y RaspberryPi using pulseaudio.

gst-launch playbin2 uri=file:///... should do that for you.


Tomas

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

Re: [yocto] [meta-raspberrypi][PATCH 0/2] Binary graphics library fixes

[Tomas Frydrych]

On 08/02/13 13:03, Andrei Gherzan wrote:
> 
> 
> 
> On Fri, Feb 8, 2013 at 12:17 PM, Tomas Frydrych
> mailto:tf+lists.yo...@r-finger.com>> wrote:
> 
> Hi Andrei,
> 
> On 07/02/13 14:26, Andrei Gherzan wrote:
> > We are moving to userland repo. So we will build our libraries
> 
> I tried to use the userland repo about a week ago and had to revert back
> to using the binary firmware; the userland tree seem to miss some bcm
> headers, so it was impossible to build apps against the libs whose
> includes require those.
> 
> 
> I will push some patches this weekend. Would you give it a try?

Time allowing, of course. But the problem was not with the meta-rpi
packaging, the files were missing in the upstream userland git repository.

Tomas

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

Re: [yocto] Creating tailored image without standard rootfs files

[Tomas Frydrych]

On 21/03/13 15:09, Peter Bergin wrote:
> for my Yocto build I want to create two separate images as output
> because in my system I have two separate partitions. One partition
> containing the root file system and one partition containing
> configuration and application data. What I want is to create an image
> only containing data and applications from my recipes that I can apply
> to my data partition.

You can post-process the rootfs before generating the image to rm the
dirs you do not want, by appending a suitable function to the
ROOTFS_POSTPROCESS_COMMAND variable.

Also, there are existing systems out here that need multiple partitions,
e.g., the SD image  for RPi (see meta-raspberrypi) contains two separate
partitions, see the sdimage bbclass for what it does.

Tomas

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

Re: [yocto] No keyboard in X

[Tomas Frydrych]

On 21/03/13 20:11, Chris Tapp wrote:
> I've got a system (Danny, meta-intel-cedartrail) with a custom
> /etc/mini_x/session file which is used to run an application at
> startup.
> 
> This all works to the extent that the application starts and runs,
> but the keyboard doesn't work - 'Esc' should cause the application to
> terminate and the X session to end. The Xorg log shows that the
> session is "Using VT number 2".
> 
> If I kill the session manually, login on the tty and restart (using
> 'init 4', 'init 5') then the application runs as before but this time
> the keyboard works as expected.
> 
> inittab runs a getty on tty1 to tty4.

Could be permissions; if you are not starting X as root, you have to
make sure the X user has rw permissions to /dev/ttyN and /dev/input/*

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

[yocto] GObject Introspection support for Yocto: meta-gir

[Tomas Frydrych]

Support for GObject Introspection is one of the gaping omissions in
current Yocto / OE coverage, and here at sleep(5) we thought it was time
someone took the bull by the horns and did something about it ... so
without further ado:

  https://github.com/Guacamayo/meta-gir

The repo contains a lengthy README that I shall not repeat here at
length, other than saying it's early days in terms of package coverage
(though everything needed to build core-image-sato is in place; a small
patch for oecore is in the repo), and undoubtedly there is scope for
improvement -- contributions are not only welcome, but invited.

The git repo is currently under the Guacamayo project because it was
convenient for us, but would be happy to move it to g.yp.o, if there was
impetus to do so.

Have fun,

Tomas
-- 
http://sleepfive.com
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] any point in a single machine recipe using a machine-specific file?

[Tomas Frydrych]

On 19/04/13 15:02, Burton, Ross wrote:
> On 19 April 2013 14:49, Robert P. J. Day  wrote:
>>   but in the case of the rpi, is there any value in putting the files
>> under a machine-named subdirectory? of course it won't hurt, but is
>> there any point to it?
> 
> You could argue the clarity that it will bring if another machine is
> added to the BSP - the maintainer will be forced to decide if it's
> common across all machines that the BSP will service, or truly is
> specific to a particular machine.

No, no, no, this has nothing to do with clarity, it's the only way in
which it can be done without breaking other machines. As Martin said,
multiple BSP layers often are included at the same time, and if a config
file pulled in by a BSP bbappend is not made machine specific (which is
what the machine specific directory means), it will be installed for any
machine that does not come with a higher priority bbappend that also
overrides this file.

As an additional point, the 'interfaces' file should not be included in
a netbase bbappend, it's not part of the netbase base package ... I
opened a bug against meta-yocto-bsp for this, but seems this is more
wide spread.

Tomas

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


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

Re: [yocto] any point in a single machine recipe using a machine-specific file?

[Tomas Frydrych]

On 19/04/13 15:15, Robert P. J. Day wrote:
> i'd wonder, if you're building for a different machine, why are
> you including the meta-rpi layer?

Because at a distro-level you often want to target different architectures.

> best answer i'd be able to give is that it's not essential but it
> won't hurt anything, which sounds kind of lame. :-)

No, it's is essential that it is done this way, BSPs are for specific
machines, so they should never install generic config files.

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

Re: [yocto] any point in a single machine recipe using a machine-specific file?

[Tomas Frydrych]

On 19/04/13 15:34, Robert P. J. Day wrote:
> On Fri, 19 Apr 2013, Tomas Frydrych wrote:
> 
>> On 19/04/13 15:15, Robert P. J. Day wrote:
>>> i'd wonder, if you're building for a different machine, why are
>>> you including the meta-rpi layer?
>>
>> Because at a distro-level you often want to target different
>> architectures.
> 
>   yes, i appreciate that but, in *this* case, we're talking about a
> single machine with a single architecture. i'm pretty sure we're
> agreeing, i'm just pointing out that in this specific example, having
> a machine-specific subdirectory is overkill.

BSP layers are not stand alone entities, they can never assume that no
other machines exist in the ecosystem they are pulled into. So, no, it
is most definitely not an overkill. I am not sure how else to explain
it, maybe fix up the RPI layer the way you intended locally and build
yourself a Qemu image, see what happens to your interfaces file.

Tomas

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

Re: [yocto] Trouble patching a package

[Tomas Frydrych]

On 22/04/13 13:56, Saridakis, Dean (US SSA) wrote:
>>> Seems like this ought to be pretty easy based on the docs - Not sure
>>> what I've got wrong. I've added an append to my layer w/
>>>
>>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>>
>>> SRC_URI += "0001-yada-yada.patch"
>>>
>>> # Comment out while debugging
>>> #PRINC := "${@int(PRINC) + 1}"
>>>
>>> The append file is in BBFILES. The patch file is in the same dir as
>>> the append file (using a files sub-dir didn't help). Been doing
>>> "bitbake -c patch -f pkg" to test/debug. (pkg is canutils, which is
>>> autconf based)
>>
>> Based on the path you're using, the patch needs to be in a subdir relative to
>> your append file. Specifically, the subdir needs to have the same name as the
>> package.
>>
>> -Kevin
> 
> I've also tried just "${THISDIR}:" with the same results.
> 
> A lot of this stuff is still magic to me & I'm not sure how to go about 
> demystifying it -- do I have to dig into the underlying classes?
> E.g., what magic is required to pick up & apply a patch file? Anything named 
> *.patch? 


>>> #PRINC := "${@int(PRINC) + 1}"

Not sure which version of Yocto you are using, but this is probably the
source of your problems -- until very recently no PR change means no
rebuild.

The other thing, if you modify SRC_URI, re-running the 'patch' task is
not enough, the patches need to be added to the sources, which happens
during the 'unpack' task.

If you are adding a patch to the bbappend, there is only two things that
can go wrong: your extra path is wrong, in which case you will get a
failure during 'unpack', or your patch does not apply, then you will get
a failure during 'patch' task. If neither of these is happening, then
your bbappend changes are not being processed.

If in doubt run 'bitbake -c cleansstate package' to start from the
beginning.

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

Re: [yocto] recipe gsl-1.15

[Tomas Frydrych]

On 09/05/13 16:48, Edward Vidal wrote:
> "file://NEWS;beginline=362;endline=363;md5=325d4344063147ef38e3ac2cbf1cc157"

You should be hashing the actual license file, not the NEWS file. Also,
the above is only hashing one line of the file, while your md5 sum is
for the whole file.

Tomas

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

Re: [yocto] [meta-raspberrypi] Thoughts on Raspberry Pi firmware

[Tomas Frydrych]

On 14/05/13 13:09, Paul Barker wrote:
> Secondly, is there any use case for building vc-graphics or 
> vc-graphics-hardfp to provide virtual/egl and virtual/libgles2
> (which rely on binary files from the raspberry pi firmware repo)
> instead of compiling from source using the userland package?

It would be preferable if we could build these from source; last time I
tried (which, admittedly, is a long while back), this was not possible
because of some missing broadcom-specific header files that seemed not
available anywhere, but I guess this is no longer the case.

Tomas


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

Re: [yocto] Commercial usage of Yocto

[Tomas Frydrych]

Hi,

On 04/06/13 05:35, Kumita Bruce wrote:
> I have one question, can Yocto be used for commercial purpose? If the
> answer is yes, what should I do before using it for commercial purpose? 

Yocto is used in scores of a great variety of commercial products out
there, which is facilitated by the broad MIT license the framework is
released under. There is nothing special you have to do to use it
commercially.

When you ship your product, you will need, of course, to comply with the
licenses of the software packages that your device uses. Yocto is set up
to facilitate this, see
http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#maintaining-open-source-license-compliance-during-your-products-lifecycle.

Tomas

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

Re: [yocto] Error including meta-oracle-java in custom image

[Tomas Frydrych]

Hi,

On 04/06/13 08:41, Marcelo Valle wrote:
> 1.
> Fetcher failure for URL:
> 'http://download.oracle.com/otn-pub/java/jdk/7u2-b13/jre-7u2-linux-x64.tar.gz'.
> Checksum mismatch!
> 
> ...
>
> To fix it i've update oracle-jse-jre-x86-64_1.7.0.bb
>  with these checksum.
> I build the image again and new error appears
> 
> 
> 
> 2.
> Function failed: Unpack failure for URL:
> 'http://download.oracle.com/otn-pub/java/jdk/7u2-b13/jre-7u2-linux-x64.tar.gz'
> 
> Unpacking
> /home/mvalle/Yocto2/poky-dylan-9.0.0/build/downloads/jre-7u2-linux-x64.tar.gz
> gzip: stdin: not in gzip format

This suggests that the original check sum failure is down to your
original download being corrupted. You should not modify the chechsums,
but rather run 'bitbake -c cleanall oracle-jse-jre-x86-64', and then
rerun the build to fetch the tarball again. Or, since you already have
the tarball, you can change the checksums back, run 'bitbake -c
cleansstate oracle-jse-jre-x86-64', then rerun the build.

(Your set up works because you manually replaced the tarball after the
sums have been verified, but if someone else tries to build your
modified recipe, it will fail on the checksums.).

> ---
> But if I try to build my custom image and the build fails with these error:
> 
> Function failed: do_rootfs
> 
> | Computing transaction...error: Can't install
> oracle-jse-jre-x86-64-1.7.0-r0@x86_64: no package provides
> libXi.so.6()(64bit)


libXi is provided by the libxi package, this should be added to the
RDEPENDS for the jre package to get it pulled into the image (looking at
the recipe there are probably other RDEPENDS missing there as well).

Tomas


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

Re: [yocto] -rt and COMPATIBLE_MACHINES

[Tomas Frydrych]

Hi Paul,

On 20/06/13 20:40, Paul D. DeRocco wrote:
> My question is this: why was I able to build core-image base without
> complaint in the first place? The kernel recipes it has available
> (linux-yocto_*) also set COMPATIBLE_MACHINE to a list of qemu machines.

It probably built the linux-dummy recipe. An easy way to see which
recipe is being used is to run 'bitbake virtual/kernel'.

Tomas

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

Re: [yocto] run commands after installation

[Tomas Frydrych]

On 26/06/13 15:32, Katu Txakur wrote:
> I want to create a user after adding the snmp recipe. The command to do
> that is:
> 
> net-snmp-config --create-snmpv3-user -a "my_password" myuser
> 
> What's the best way to do it? I have tried from do_install_append and
> also from ROOTFS_POSTPROCESS_COMMAND but no luck so far.

You need a postinst script for that sort of a thing.

Tomas

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

Re: [yocto] [meta-raspberrypi] Userland and vc-graphics

[Tomas Frydrych]

On 06/07/13 12:22, Paul Barker wrote:
> So if there recipes are fulfilling the exact same purpose, I think we
> should strip out vc-graphics completely and always build from source.
> I've never seen a use case for the pre-compiled vc-graphics recipes
> within OpenEmbedded/Yocto.
> 
> Does anyone else who's worked with meta-raspberrypi agree with this?
> If so I'll throw together patches to achieve this.

vc-graphics is the original package before the userland sources were
made available; in principle the two should be equivalent, but the last
time I tried to build userland, which admittedly is two or three months
back, it was failing miserably due to some missing broadcom headers that
were nowhere to be found among the released sources. I assume the
userland packages now build OK?

Tomas


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

Re: [yocto] Changing syslinux configuration

[Tomas Frydrych]

On 06/07/13 02:23, Paul D. DeRocco wrote:
> Does anyone know what recipe actually sets LABELS?

The relevant image classes do.

Tomas


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

[yocto] Not booting on BeagleBoard xM 0x2

[Tomas Frydrych]

Hi,

I am trying to get Yocto image built from yesterday's master
(Linux-3.0.23-yocto-standard) to boot on the NAND-less version of
BeagleBoard xM, but the kernel panics with:

- console log start 

Waiting for root device /dev/mmcblk0p2...
mmc0: new SDHC card at address 1234
mmcblk0: mmc0:1234 SA04G 3.67 GiB (ro)
 mmcblk0: p1 p2

VFS: Cannot open root device "mmcblk0p2" or unknown-block(179,2)
Please append a correct "root=" boot option; here are the available
partitions:

b300 3858432 mmcblk0  driver: mmcblk
  b301  120456 mmcblk0p1 ----0mmcblk0p1
  b302 3445942 mmcblk0p2 ----0mmcblk0p2

VFS: Unable to mount root fs on unknown-block(179,2)
User configuration error - no valid root filesystem found
Kernel panic - not syncing: Invalid configuration from end user prevents
continuing

-- console log end 

My guess would be the problem is the card being detected as 'ro' (line
3), but I do not know why that is (there is no lock switch on mmc cards).

The card itself is fine, it's the original card that came with the
board, the original Angstrom demo boots fine from it, and yocto kernel
2.6.37 also used to boot.

Tomas


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

Re: [yocto] Not booting on BeagleBoard xM 0x2

[Tomas Frydrych]

On 04/04/12 15:10, Gary Thomas wrote:
> On 2012-04-04 06:50, Bruce Ashfield wrote:
>> On 12-04-04 08:04 AM, Andrea Galbusera wrote:
>>> Hi Tomas,
>>>
>>> On Wed, Apr 4, 2012 at 12:14 PM, Tomas Frydrych
>>>  wrote:
>>>> Hi,
>>>>
>>>> I am trying to get Yocto image built from yesterday's master
>>>> (Linux-3.0.23-yocto-standard) to boot on the NAND-less version of
>>>> BeagleBoard xM, but the kernel panics with:
>>>>
>>>> - console log start 
>>>>
>>>> Waiting for root device /dev/mmcblk0p2...
>>>> mmc0: new SDHC card at address 1234
>>>> mmcblk0: mmc0:1234 SA04G 3.67 GiB (ro)
>>>> mmcblk0: p1 p2
>>>>
>>>> VFS: Cannot open root device "mmcblk0p2" or unknown-block(179,2)
>>>> Please append a correct "root=" boot option; here are the available
>>>> partitions:
>>>>
>>>> b300 3858432 mmcblk0 driver: mmcblk
>>>> b301 120456 mmcblk0p1 ----0mmcblk0p1
>>>> b302 3445942 mmcblk0p2 ----0mmcblk0p2
>>>>
>>>> VFS: Unable to mount root fs on unknown-block(179,2)
>>>> User configuration error - no valid root filesystem found
>>>> Kernel panic - not syncing: Invalid configuration from end user
>>>> prevents
>>>> continuing
>>>>
>>>> -- console log end 
>>>>
>>>> My guess would be the problem is the card being detected as 'ro' (line
>>>> 3), but I do not know why that is (there is no lock switch on mmc
>>>> cards).
>>>>
>>>> The card itself is fine, it's the original card that came with the
>>>> board, the original Angstrom demo boots fine from it, and yocto kernel
>>>> 2.6.37 also used to boot.
>>>>
>>>> Tomas
>>>
>>> Looks related to the comment I wrote here:
>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=1892
>>> I have a slightly different failure with yocto 1.2 beta snapshot (same
>>> kernel) but seems related. Needs more investigation.
>>> Anyone else having problem booting on beagleboard xM? Seems something
>>> wrong happened after 1.1 release...
>>
>> We are working on several bugs on our reference beagleboard. The problem
>> is that my beagleboard died (a horrible painful death) and the other
>> boards
>> that are directly available to are RevC and they are booting. So things
>> are slowed down a bit .. but we are trying to get to the bottom of it,
>> as fast as possible.
> 
> Just FYI, it also doesn't boot on my rev-C3 (not xM), albeit with a
> different
> error pattern.  It hangs at this point:
>   Waiting for root device /dev/mmcblk0p2...
>   mmc0: error -110 whilst initialising SD card
> 
> Looks like you might need the attached patch?

This is a different issue. I get this too with one particular MMC card,
but with 2.6.37 kernel, if I unplug this card and plug it back in the
boot resumes and completes successfully. If I do this with the 3.0.2
kernel, the bug I described with the associated kernel panic then kicks in.

Tomas

> 
> 
> 
> ___
> 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] using and auditing kernel config fragments

[Tomas Frydrych]

Hi,

I am trying to add a kernel config fragment to the yocto 2.6.37 kernel
for BeagleBoard, because I need a driver for a rt2800usb dongle.

For some reason which I cannot work out, the rt2800usb options are
removed (rather then disabled) from the yocto kernel config, i.e., if I
run 'bitbake -c menuconfig linux-yocto', there is very little under
Drivers->Net->WLAN. If I run menuconfig in the devshell, there are lots
more WLAN drivers available, including the rt2800.

So, I created custom fragment with the appropriate options, which works
to the extent it gets picked up, but then the options are removed during
the kernel_configme process and end up in the missing_required.cfg, and
there is no information I can find anywhere in the logs as to why this
is the case. Any ideas how to find out what the problem is?

(I am using yocto master)

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

Re: [yocto] using and auditing kernel config fragments

[Tomas Frydrych]

On 06/04/12 14:40, Autif Khan wrote:
> I forgot to mention - Under Networking Support -> Wireless, you need
> to enable cfg80211 AND msc80211 (Generic IEEE 802.11 Netowrking Stack)
> 
> Then the Ralink driver support shows up under Wireless LAN

Thanks, that's the bit I was missing. :)

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

[yocto] managing layer priorities

[Tomas Frydrych]

Hi,

Is there a way to change the priority that a layer assigns itself in its
layer.conf? E.g., I want to add meta-oe alongside of meta-yocto, but I
want it to have a lower priority than the latter. Currently meta-yocto
gives itself "5" and meta-oe "6", I'd like to change this without having
to modify meta-oe/conf/layer.conf, but can't find a way to do this.

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

Re: [yocto] managing layer priorities

[Tomas Frydrych]

On 08/04/12 23:28, Tomas Frydrych wrote:
> Is there a way to change the priority that a layer assigns itself in its
> layer.conf? E.g., I want to add meta-oe alongside of meta-yocto, but I
> want it to have a lower priority than the latter. Currently meta-yocto
> gives itself "5" and meta-oe "6", I'd like to change this without having
> to modify meta-oe/conf/layer.conf, but can't find a way to do this.

Never mind, it is possible to override these in the last layer listed in
BBLAYERS.

Tomas

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

Re: [yocto] managing layer priorities

[Tomas Frydrych]

On 09/04/12 14:04, Gary Thomas wrote:
> On 2012-04-09 00:18, Tomas Frydrych wrote:
>> On 08/04/12 23:28, Tomas Frydrych wrote:
>>> Is there a way to change the priority that a layer assigns itself in its
>>> layer.conf? E.g., I want to add meta-oe alongside of meta-yocto, but I
>>> want it to have a lower priority than the latter. Currently meta-yocto
>>> gives itself "5" and meta-oe "6", I'd like to change this without having
>>> to modify meta-oe/conf/layer.conf, but can't find a way to do this.
>>
>> Never mind, it is possible to override these in the last layer listed in
>> BBLAYERS.
> 
> How so?

You can set the various BBFILE_PRIORITY_ and other variables in the
layer.conf for the last layer listed in your bblayers.conf. The layer
priorities get evaluated only after all of the layer.conf files have
been parsed, so anything that is set in the last layer.conf will be the
final value. I use the Yocto model where (unlike with OE layers) the
layer.conf prepends its layer path to BBPATH, so my custom layer is
last, but I imagine it would be possible to create a fake layer with no
recipes just for this specific purpose.

Tomas

> 

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

Re: [yocto] managing layer priorities

[Tomas Frydrych]

Hi Paul,

On 09/04/12 15:09, Paul Eggleton wrote:
> On Monday 09 April 2012 14:58:49 Tomas Frydrych wrote:
> I realise what you're trying to do, but you should bear in mind when you do 
> this you are relying on unintentional behaviour that may change in future.

I am not sure whether unintentional is an accurate description; layer
priority is explicitly and intentionally the function of other layers
due to inter-layer dependency. So I prefer to think of it as an
undocumented feature. :-) But I know, if it does not work, it's my own
fault.

The reason for doing this is that I'd like to be able to treat an
external layer as a read-only entity, and to enforce this. My experience
suggests that if you fork external layers alongside your custom layers,
this over time leads to unnecessary maintenance costs. On the other
hand, if each external layer is a read-only entity, it can be integrated
as a read-only git submodule, and no naughty developers will then make
changes to it.

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

Re: [yocto] [Yocto] How to remove a particular package or packages collection for an image

[Tomas Frydrych]

On 10/04/12 08:20, Jegan Chandru wrote:
> I did  dry-run on core-image-custom and I see mostly all packages from
> yocto included in my image, the packages that I do not need. So, how can
> I remove a particular package or a package collection, say graphics or
> some X packages for my image. Is it possible? or can core-image.bbclass
> is overwritable? Does my approach ok?
> 
> Any help in achieving this is much appreciated.

The basic package selection in the Poky/Yocto images is done on basis of
the DISTRO_FEATURES variable, so you need to set this somewhere suitable
to only include the components you need (iirc, the default package
selection is quite rich).

Other than that, bitbake -g  generates .dot files that show
package dependencies, so you can work out why particular package is
being included.

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

Re: [yocto] Network booting

[Tomas Frydrych]

On 31/07/13 21:30, Chris Tapp wrote:
> Is there an easy way to have a system boot and load the rootfs from a
> network server?
> 
> I'm using an x86 system and can have the kernel and an initrd on it.
> I would use bootp, but a lot of end users either don't have this or
> will not allow it to be used. I think it needs to go something like:
> 
> 1) Kernel loads the initrd and bring the network up (static or
> DHCP); 2) The rootfs image can then be download; 3) Some magic then
> makes this run...
> 
> This would allow easy update of the rootfs and makes it non-volatile
> (which is good for this project).

It's relatively easy to add support for tftp to the yocto live image
scripts; this allows you to either boot from the network, or install
from the network. I have have some raw patches kicking around, that add
support for both tftp and scp, I have been meaning to clean it up and
post an rfc to the list, I'll try to get that done this week.

Tomas

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

Re: [yocto] Network booting

[Tomas Frydrych]

Hi Chris,

On 01/08/13 09:08, Tomas Frydrych wrote:
> On 31/07/13 21:30, Chris Tapp wrote:
> It's relatively easy to add support for tftp to the yocto live image
> scripts; this allows you to either boot from the network, or install
> from the network. I have have some raw patches kicking around, that add
> support for both tftp and scp, I have been meaning to clean it up and
> post an rfc to the list, I'll try to get that done this week.

I am attaching the patches I have, it's a bit raw, and needs more work
before submitting for consideration in oe-core, but I think out of the
box tftp support would be useful to have somewhere.

The patches include changes to the live/install scripts from the oe-core
initramfs recipes and an image recipe for an initrd image with the
necessary tools (I initially started to write separate recipes for the
scripts, but realized quickly that the differences from the standard
live image bits are so small that's hardly justified in comparison to
the increased maintenance burden.)

The main changes to the scripts are:

 * use syslinux instead of grub, makes life lot simpler, 'naf said,
 * rework the install script so that unassisted install is possible,
 * support tfpt for kernel/rootfs loading, and scp for rootfs loading,

The test-ssh-key recipe provides a dummy (i.e., compromised) ssh key
that can be used for rudimentary testing of using scp for kernel
loading; scp is potentially useful for remote system updates from
outside of LAN boundaries, but a real set up would need bit of thought
on how to manage the real keys, etc.

The net-image also generates a sample config file for PXELinux in the
deploy/images directory (net-image.pxelinux.cfg), which documents fairly
well how to set it up. I hope this is of some use, at least to foster
more discussion. :)

Tomas

-- 
http://sleepfive.com
>From 53e082c2b3eed2b1dafc604452d0414b6cdd9478 Mon Sep 17 00:00:00 2001
From: Tomas Frydrych 
Date: Thu, 1 Aug 2013 10:24:19 +0100
Subject: [PATCH 1/4] test-ssh-key: dummy ssh key for testing of scp
 functionality

---
 meta/recipes-support/test-ssh-key/test-ssh-key.bb |   73 +
 1 file changed, 73 insertions(+)
 create mode 100644 meta/recipes-support/test-ssh-key/test-ssh-key.bb

diff --git a/meta/recipes-support/test-ssh-key/test-ssh-key.bb b/meta/recipes-support/test-ssh-key/test-ssh-key.bb
new file mode 100644
index 000..1e8fc86
--- /dev/null
+++ b/meta/recipes-support/test-ssh-key/test-ssh-key.bb
@@ -0,0 +1,73 @@
+DESCRIPTION = "Private ssh key for root user (for testing purposes only!)"
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = "file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58"
+
+# NB: THIS PACKAGE MUST NOT BE USED ON PRODUCTION IMAGES
+#
+# This package is intended for testing purposes only; it suffers from a number
+# of flaws:
+#
+#1. The private key is not private and hence already compromized
+#
+#2. The ssh config file is set up to avoid integrity checks on server keys
+#   -- real set up would need to include a suitably pre-populated
+#   known_hosts file.
+
+inherit allarch
+
+# SSHKEY and SSHKEY_PUB are variables, but are declared as functions so we
+# can use line breaks (a real package would source this from a file)
+
+SSHKEY () {
+-BEGIN RSA PRIVATE KEY-
+MIIEowIBAAKCAQEAquOX/60//MR1gHpOjjTBkp4kl9Ry7ig3WY/r9h8nq3ody9zu
+tJmMIpTJKbDy0ZlSeFtE2ZwBrDBceuECH8jvHQC8EH3gj49eSwVOwbQu4A7ZdN0V
+l0Vm2vgG0Xvs3o2HzONm6NWYCrj2UfCeIeYrDFBuFpvCZSYxvw/qz9G8oSmi2brJ
+/Oqqz1BeAqgWraDwprdkQ7GHSNfkPdSZW+b1F/Gr2TTDU4N6IGGSgrMUxZZsf1kC
+D10qv73WyU3WODW5oycxw0kS7AisQis9A9n2XispYDfJuN3Fp6WcWI5GgILjqSWG
+g/rtvWU8EpK/nNJGei+cHXcFa8odzCVOqNO8lwIDAQABAoIBAQCiHgoL33Mtu77x
+JJazp+7fxjFW7JAfyX1A9R1YP5QlxFLSHQVDxctA3z+70od5OmgXkBZQDwUzMin5
+1M5sEvZs4E6JorFP4CYHK8DcWLCDlPLNQBQEjy2Vm+j0AQnk1AW55R2y0zdLLM9Z
+Stjpte6u3vqhbiDMTqCw7kvH3eSCSm2yV8e7ydFpRZxMjMcSNovjqq+hqSLKcLGL
+F4WoYotA5vomGT4D1YWWzD03QgElVnGT+VrOt0PtC5QHWvlsmkuZWeJukNOFLip7
++DH6/9fbTskO43O7p3tC1Lq1TkqUrXTJfUrVr5qjw6Nl07lO/gC/qFULA0FjUf8F
+Ayt7Ax35AoGBANR0+1FEvBBt5R16sdsbUdqLHMAq2efE0UdHSvyrIboj1frI+Xgn
+iN4p3rrJdWeKBJL4YH4XeOT/XYAmmfvffhEeiF1zB1Wy5/63TABXDf/uvh3GyO8P
+iL1ev0rswU56yqcQrX/j7SfOUtZwVyYnqblfemG/6v45uxdLyegDM8gNAoGBAM3p
+qQbJ8FDvgL9WoiRFN75bpV2wkx8ukHGfZt6I1nFvXreAwAa6zD5zxHjdn2R+sQUV
+wlqvgDjFjdp6xDiXMrsV47RSjJiByo15d+6jdXhZ8jrXXOYrZ4qDXE/wSnSei9bl
+iE82paKTNEeT7pz5psNf/DlRcb10ykX8Urgag+ozAoGAV5LYvQj+FC+YT2xxv4Ul
+WlYZRcTkCTsBoMXsTPYlctquqy8IVdTF//12R7we3szvUb172L3IIWx5mAdRVZcs
+GdZiE1ME5PhX1JCtjT5VEPfR+egkjxXyIUzawQGSNM08l1yyh5LmAJB1aNrpsVqM
+BVMr2PsI3D3jtpiQ40feokkCgYAuzV1N3bhxrP5mfxp7hAAXlF0R3oCSJdNPABwx
+mIilX9r3epwq62phB48wqa8A+IrjzP5P/nP2c3C6qAzRkAxH2cHXyquKPnX7khBg
+fWbF5Cvak/jZmCQAp7rjsIo7142RWrqQxqr/ONY5Lradl2EAJ2D85jYkCdev8Joc
+nmo9YQKBgG3EjvO1yJ0JxuImSNGq4W/2e8cXPMW/XTenQztPALU5mAAvxSCp7pi2
+zNmv60E3QHbdB4arglV73oCdGVpgFAamQbzvmVe9UptYs/iFVGIfktqlFqI7DelM
+4NmUlKy0OYMGvQ348Sg6trWQnaiw+F2I/X

Re: [yocto] Network booting

[Tomas Frydrych]

On 01/08/13 19:53, Chris Tapp wrote:
> I think it is ;-) I think I'll still need to use ipxe as I need to be
> able to boot without DHCP support as well.

Depends on the bios, if your machine's bios supports PXE, then you do
not need ipxe, just a tftp server set up on the LAN that serves PXELinux.

I am wondering if having a thin meta-pxe layer would be useful to pull
some of this together both code and people interested, or whether we
should aim adding this functionality to OE-core?

Tomas


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

Re: [yocto] Network booting

[Tomas Frydrych]

On 02/08/13 08:35, Chris Tapp wrote:
>> Depends on the bios, if your machine's bios supports PXE, then you
>> do not need ipxe, just a tftp server set up on the LAN that serves
>> PXELinux.
> 
> My case is a bit more complicated as I also can't have non-secure
> (t)ftp! Are you saying that PXE can work without DHCP/BOOTP?

It probably depends on the BIOS, iirc, standard PXE does not support
anything other than tfpt, but you can probably configure the IP settings
manually, and I think the bios on the machine I was working with
supported https (but I am not 100% sure, and can't check at the moment).
iPXE supports https, of course, so we definitely want iPXE recipe and
documentation.


> It would benefit from some scripting support in the image to
> personalise it as it boots (e.g. setting IP configuration, hostname,
> etc.) - I'm currently looking to do this by passing parameters back
> from the server through the kernel command line.

Yeah, but keep in mind that the stuff only happens 'in the image' when
you have already booted, so you can only script stuff to do with the
rootfs in the image; the kernel and initrd is loaded by the PXE
bootloader so the control here is whatever the PXE bootloader gives you.

Tomas

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

Re: [yocto] Sending mail from embedded device

[Tomas Frydrych]

On 06/08/13 18:27, Gary Thomas wrote:
> On 2013-08-06 10:01, Mark Hatle wrote:
>> 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.)
> 
> And almost enough for my needs.  Amanda wants to use an MTA that
> works like the desktop 'mail', e.g.
>   mail -s "subject" TO  I wrote a simple wrapper to use msmtp/sendmail and it works fine.

I can confirm mstp works very well, and with all the necessary bells and
whistles like TLS. If you need more complex messages (e.g.,
attachments), then libgmime makes composing the email messages to pipe
into mstmtp quite easy.

Tomas


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

Re: [yocto] How to customize a file coming from another recipe?

[Tomas Frydrych]

Hi,

On 11/09/13 20:24, Brad Litterell wrote:
> This installs a default configuration file for the service which I now
> want to customize.  What is the recommended way to overwrite or
> customize files in another package?
> 
> Is the best course to create a recipe bbappend for the
> lighttpd_1.4.31.bb file that is being used?

Yes.

> And can I just include a
> new file with the same name in my append and will it overwrite the old
> one, or do I need to create an actual patch file?

Assuming you set up the FILESEXTRAPATHS in the bbappend correctly (as
per documentation), you can just provide the whole file, it just takes
the first instance of the file it locates in the files path.


> Or is it better to create a new separate  recipe that just ships my
> version of the configuration file? How are conflicts handled when two
> recipes attempt to install the same file?

No, do not do this, two packages can't install the same file (if the
file is being staged to the sysroot, bitbake will catch that, but I am
not sure if currently that throws and error or just a warning; in your
case with a file that is not staged in a sysroot the problem would only
become apparent at rootfs time, but I am not sure how the different
package managers handle this).

Tomas

> 
> Thanks,
> Brad
> 
> 
> 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
> 


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

Re: [yocto] Build time data

[Tomas Frydrych]

On 12/04/12 01:30, Darren Hart wrote:
> Next up is storage. 

Indeed. In my experience by far the biggest limiting factor in the
builds is getting io bound. If you are not running a dedicated build
machine, it is well worth using a dedicated disk for the poky tmp dir;
assuming you have cpu time left, this leaves the machine completely
usable for other things.


> Now RAM, you will want about 2 GB of RAM per core, with a minimum of 4GB.

My experience does not bear this out at all; building Yocto on a 6 core
hyper threaded desktop machine I have never ever seen the system memory
use to get significantly over a 2GB mark (out of 8GB available), doing
Yocto build using 10 cores/threads.


On a custom desktop machine with i7-x990 3.47GHz, 8GB ram, quiet
conventional hard disks, letting poky use 10 cores/threads (so I can get
my work done while it does its own thing in the background), a fresh
build of core-image-minimal for beagleboard, with debug & profile tools
and test apps, takes 77 minutes.

Obviously, not anywhere near as fast as the Intel OTC Xenon beast, but
much cheaper HW, and for my purposes the build speed is well in a region
where it is no longer a productivity issue.

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

[yocto] Raspberry Pi [was Re: Kernel modules fail to compile for ARM]

[Tomas Frydrych]

On 14/05/12 19:52, Chris Tapp wrote:
> I'm trying to put a BSP together for an ARM system (Raspberry Pi, 
> ARM1176JZF-S CPU). 

I got the feeling that there might be multiple OE/RPI efforts going on
at the same time unaware of each other, e.g., I noticed this
meta-raspberrypi layer on github that seems to be well on the way,
https://github.com/djwillis/meta-raspberrypi ... perhaps getting various
folk interested in this together would be beneficial.

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

Re: [yocto] Raspberry Pi [was Re: Kernel modules fail to compile for ARM]

[Tomas Frydrych]

Hi Bruce,

On 15/05/12 16:44, Bruce Ashfield wrote:
> On 12-05-15 05:15 AM, Tomas Frydrych wrote:
>> On 14/05/12 19:52, Chris Tapp wrote:
>>> I'm trying to put a BSP together for an ARM system (Raspberry Pi,
>>> ARM1176JZF-S CPU).
>>
>> I got the feeling that there might be multiple OE/RPI efforts going on
>> at the same time unaware of each other, e.g., I noticed this
>> meta-raspberrypi layer on github that seems to be well on the way,
>> https://github.com/djwillis/meta-raspberrypi ... perhaps getting various
>> folk interested in this together would be beneficial.
> 
> I'll jump in and ask my obvious question, if we want to pull in some
> extra BSP/kernel developers, is there a fundamental reason why a
> different kernel/kernel version than one of the linux-yocto ones is
> being used ?
> 
> If you line up with one of those, there's a chance to pickup fixes,
> features and have someone like me help maintain things where it
> makes sense.

Let me turn this question back at you then: is Yocto going to be doing
thorough Q&A for all of these HW platforms? Decent Q&A is what really
sets Yocto apart, and what makes it my first port of call, but I got a
feeling that the scope of this is at the moment somewhat restricted as
far as HW is concerned; without Q&A 'fixes' quickly turn into problems
-- I'd rather be pulling kernel from somewhere that deals with the
specific HW that pick up generic fixes without the Q&A.

(Though admittedly working with some silicon vendors specific meta
layers can be real PITA :) ).

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

Re: [yocto] Raspberry Pi [was Re: Kernel modules fail to compile for ARM]

[Tomas Frydrych]

Hi Bruce,

On 15/05/12 19:07, Bruce Ashfield wrote:
> On 12-05-15 01:36 PM, Tomas Frydrych wrote:
>> Let me turn this question back at you then: is Yocto going to be doing
>> thorough Q&A for all of these HW platforms? Decent Q&A is what really
>> sets Yocto apart, and what makes it my first port of call, but I got a
>> feeling that the scope of this is at the moment somewhat restricted as
>> far as HW is concerned; without Q&A 'fixes' quickly turn into problems
>> -- I'd rather be pulling kernel from somewhere that deals with the
>> specific HW that pick up generic fixes without the Q&A.
> 
> I spend all day every day working with targets across the spectrum of
> arch and use case, with plenty of drivers and core infrastructure
> in common, so those sorts of changes being monitored and being included
> are definitely in place.

Cool, but a developer working with targets does not really qualify as
QA. QA implies testing that culminates in a formal release.


> As for hardware specific QA, the yocto project itself runs QA on targets
> that we've tagged as a hardware reference. The raspberry pi is one that
> I've been considering as a new reference, so if that was the case, it would
> get extra coverage.

It is certainly an interesting / high profile enough board to be of
interest to Yocto as a project I think.


> That being said, it obviously doesn't scale that just because we align
> on a kernel version, set of features, base configuration, etc, that
> the yocto project itself would run machine/BSP specific QA. That would
> be a place where interested parties would already be doing QA,

This is where it becomes problematic. Interested parties simply cannot
be relied on doing QA, that was pretty much why Poky came to be (BTW,
'git tag' provides a rudimentary insight into project QA mentality; the
absence of release tags invariably means no QA worth mentioning and pain
in store ... an interesting exercise when it comes to meta-*).

So, if meta-yocto contains machine/.conf I expect
meta-yocto to be providing quality assured images for . If
Yocto can't do that, I question the value of including it at all.


But that aside, I'd very much recommend that the RPI kernel for
meta-rasberrypi to be based on the Yocto kernel tree; as a Yocto user,
rather than a kernel developer, the whole config fragment machinery
provides a very clean and controlled way of managing the kernel and is
really nice to work with. :-)

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

Re: [yocto] [poky] RaspberryPi Layer

[Tomas Frydrych]

Hi,

On 19/05/12 22:51, Andrei Gherzan wrote:
> After an exchange of messages with Richard, Saul and John Willis (he
> already started a layer for oe and did a good job in it) i want to
> announce that i started start a fork from his layer and with Florin
> Sarbu will prepare a layer for RaspberryPi to work upon poky. 

Why a fork? This is a bsp layer so it should be sufficiently generic to
work both with Poky and OE, it is really undesirable that there should
be more than one m-rpi layers in circulation.

> Until a stable version of this layer we will keep this layer on
> bitbucket: https://bitbucket.org/agherzan/meta-raspberrypi. 

Considering that John Willis's work is on github, where a number of
people follow it already, why move this somewhere else? This just makes
it harder for anyone interested in this work to track what is going on.

My suggestion is to set up a github project for this, move John's repo
under that as the master, and then any temporary tweaking for poky and
otherwise can be done branches rather than separate repositories.

> I don't know if a mailing list is needed but if there are any others who
> want to contribute on this, we can adopt meta-fsl-arm's solution of a
> google group and use it as a way of communicating. 

I think mailing list is needed; please do not use a group for this, and
certainly not one that requires a google login. Perhaps Yocto could let
us have a meta-rpi list?

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

Re: [yocto] [poky] RaspberryPi Layer

[Tomas Frydrych]

Hi,

On 21/05/12 09:47, Andrei Gherzan wrote:
> There are issues that cannot be solved with just one layer. A distro is
> a workaround but still. More about this, rpi layer will be included in
> yocto project repos as  Richard plans so it makes sense to have a yocto
> specific layer. It could be a discussion here about using a core layer
> and above that some distro specific layers but in my opinion this would
> be a little too complicated for this. Right now i use a distro file
> which inherits poky distro in order to BBMASK some bbappends which we
> don't have in poky. Clear now?

This really needs to be a BSP layer, not a distro, so that people can
build a custom distros with it; i.e., the fact that you currently BBMASK
packages in the BSP configuration means it will not be useable as an
independent layer.

> > Until a stable version of this layer we will keep this layer on
> > bitbucket: https://bitbucket.org/agherzan/meta-raspberrypi.
> 
> Considering that John Willis's work is on github, where a number of
> people follow it already, why move this somewhere else? This just makes
> it harder for anyone interested in this work to track what is going on.
> 
> 
> I'm not a github user. But this wouldn't be a problem. I find bitbucket
> a better place to hold any kind of git repo: it has collaborative
> options, you can have private repos (free) and a bunch of other stuff.
> And after all it is a git. You can clone it, fetch and pull anywhere on
> your computer. So i don't find this a problem.

It should be easy for people interested in the m-rpi effort to track
what is happening, splitting it over multiple online services does
facilitate that; more so it implicitly turns this into two separate
projects simply because someone wanting to contribute will have to
choose where to send the contributions to.

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

Re: [yocto] [poky] RaspberryPi Layer

[Tomas Frydrych]

So, I have run into three issues with the meta-raspberrypi layer when
trying use it with Poky:

 * the libav bbappend; this can be BBMASKED on distro level, so that's
not a significant problem,

 * rpi-zram-service: a simple but rather hackish fix is to provide
rpi-zram-service-initd package that provides the same functionality for
sysvinit (not a big task) and then BBMASK it in the distro. But I am
wondering if there is some way that both -systemd and -initd packages
could be generated from the same recipe in a way that would work for
both setups so we can avoid the masking?

 * GCC seems to have issues generating armv6 code; I have run into this
bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47719.

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

Re: [yocto] Per-machine DEPENDS

[Tomas Frydrych]

On 23/05/12 08:55, Chris Tapp wrote:
> Do overrides work with any variable? The RPi layer is using BBMASK to
> filter out some recipes when building against Yocto. This has to be
> manually added to local.conf. 

It does not have to be local.conf; if you are adding meta-raspberrypi,
you have to set up the layer configuration at minimum, and probably
other things, so you can set it up somewhere more appropriate.
local.conf is really just for changes when testing things, etc.

> Would it be possible to do this
> automatically in the layer using an override based on the distro
> name/version? e.g. could something like the following be added to the
> layer.conf file?
> 
> BBMASK_poky_7.0? += " ${LAYERDIR}/stuff-i-dont-want"

I don't know if the overrides work with this variable in particular, but
even if they did, it is not a good idea for a layer of any kind to be
changing the BBMASK value, because the layer cannot make any assumptions
about what might or might not be appropriate to mask out.

(Also note that BBMASK is pyton regex, so BBMASK += "
${LAYERDIR}/stuff-i-dont-want" will not work, it would need, e.g., to
include the '|' operator)

> 
> Or would it be better to have distro-specific recipe trees

Specifically to the m-rpi, there are only two problematic recipes, the
libav.bbappend, but you only know on the distro level whether you need
to mask this out or now (i.e., someone's poky-derrived distro might well
include libav).

The second is the rpi-zram-service which needs systemd.
This recipe needs to be reworked so it produces both -systemd and -initd
packages, from which the distro can then pull in the appropriate one;
one of the packages can even be a dummy (which for poky could be
achieved by adding systemd.bbclass stub).

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

Re: [yocto] Hob implementation: vanilla or branded?

[Tomas Frydrych]

Hi,

On 31/05/12 17:55, Barros Pena, Belen wrote:
> I would like to know what the Yocto Project community thinks about these 2
> approaches.

Vanilla please, 'branded' applications are so 1990s. I think very few
users care whether an application looks different on a different OS then
their own, but we all get very frustrated when an application brakes the
normal paradigms of our OS.

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

Re: [yocto] RaspberryPi Kernel - sometimes it works, sometimes it doesn't

[Tomas Frydrych]

Hi,

On 10/06/12 12:30, Chris Tapp wrote:
> I've been building the 3.1.9 Raspberry Pi kernel under Denzil using
> the meta layer at https://github.com/djwillis/meta-raspberrypi. This
> uses a kernel recipe based on the git repository at
> https://github.com/raspberrypi/linux/commits/rpi-patches.
> 
> Some of the kernel commit IDs (e.g.
> 94fbbc4e3988075abad0d3b32842b82c590324fc) seem to build ok, but they
> don't always run. As in, if I -c clean and build then sometimes I end
> up with a bootable image, sometimes I don't. I'm not changing
> anything else in the build environment.
> 
> Any ideas what can cause this?

I find that -c clean does not work very well, afterward the package gets
recompiled but instead of the actual package packages being rebuilt, an
earlier version of the packages gets pulled out of sstate into the
image. I definitely saw this behaviour with Yocto kernels, but I think
happens with other packages as well; I always do -c cleansstate now to
avoid this.

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

Re: [yocto] RaspberryPi Kernel - sometimes it works, sometimes it doesn't

[Tomas Frydrych]

On 11/06/12 17:29, Paul Eggleton wrote:
> On Monday 11 June 2012 06:53:32 Khem Raj wrote:
>> On 6/11/2012 12:29 AM, Tomas Frydrych wrote:
>>> I find that -c clean does not work very well, afterward the package
>>> gets recompiled but instead of the actual package packages being
>>> rebuilt, an earlier version of the packages gets pulled out of
>>> sstate into the image. I definitely saw this behaviour with Yocto
>>> kernels, but I think happens with other packages as well; I always
>>> do -c cleansstate now to avoid this.
>>
>> yes thats the intended behavior if nothing changed that ensues a
>> recompile then it will use precompiled sstate for the package
> 
> To clarify, it's designed to be able to determine when the recipe has changed 
> in such a way that it needs to be rebuilt (by building up dependencies 
> between 
> variables and computing a checksum of the value of each one, which ends up in 
> a checksum for each task); if it sees no change then the previous task output 
> will be used from the sstate cache. It's worth noting however that until 
> recently (post-1.2) we did not handle when local files referred to in SRC_URI 
> changed. There also still may be other circumstances under which changes to 
> the recipe or variables which it refers to will not change the sstate 
> checksums; if you come across a situation where you made a change and sstate 
> was re-used when you expected it to be rebuilt, please raise it.

Over years of working with Poky I have developed this sort of a normal
work flow:

  bitbake -c devshell 
  < do some tweaking >
  bitbake -c compile -f 
  bitbake   < this pulls package from sstate!!!
  scp ...
  < test, repeat>

This no longer works, even after a forced recompile, Poky just pulls a
package out of sstate. It seems the only reliable way to force a package
rebuild is either to cleansstate or bump the PR, neither of which is
viable an option in the above scenario. What am I missing? Is this
really intended?

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

Re: [yocto] Not booting on BeagleBoard xM 0x2

[Tomas Frydrych]

On 13/06/12 03:34, Bruce Ashfield wrote:
> On Tue, Jun 12, 2012 at 7:38 PM, Ryan Julian  wrote:
>> Hi Bruce,
>>
>> The build I'm using already includes Denys' patch.
>>
>> I was referring to Tomas' original problem, in which the MMC card
>> successfully initialized, but the kernel still panics while trying to mount
>> mmcblk0p2. These two seem unrelated, unless I'm mistaken.
> 
> The two issues that we worked with ended up both being resolved by the preempt
> disable patch. Both stemmed from the MMC card not being recognized, and that
> was due to in kernel preemption.

IIRC, both of these went away with a kernel update, but I am now using a
kernel from meta-ti, so I can't verify that.

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

Re: [yocto] RFC: poky-tiny: init procedure

[Tomas Frydrych]

Hi Darren,

On 14/06/12 01:33, Darren Hart wrote:
> o Do not include the standard Busybox init
...
> o Do not provide inittab functionality

I am not entirely clear what you are hoping to gain by creating a home
grown init solution?

A system that runs nothing but a shell is really not useful for anything
all, everyone using it will be adding some sort of services, so the
question of how the extending works (or does not work), needs to be in
the forefront of the design. My main reservation is that you are
suggesting to break one of the basic premisses behind the whole
ecosystem, namely that if I add a package that provides a service to an
image, I get that service running; 'fix by documentation' is never a fix.

So back to my original question, what are the expected benefits to the
Poky users of not using initd in such minimal systems, and do you have
any numbers to show it is worth it? Maybe the numbers are compelling,
but considering that currently Poky does not even support systemd,
adding yet another, home grown, init system seems like a step in the
wrong direction (perhaps sorting out the systemd mess is an opportunity
to deal with the init sequence in a more generic way).

(I hear what you are saying about a system that only includes packages
you want and nothing else, but this is orthogonal to the system size; I
for one want to be able to create a midsized system that includes only
packages that I want and nothing else. :) )

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

Re: [yocto] Help needed understanding do_rootfs error

[Tomas Frydrych]

Hi,

On 14/06/12 22:42, Chris Tapp wrote:
> On 14 Jun 2012, at 21:44, Chris Tapp wrote:
> 
>> The log for do_rootfs is showing: < snip > error: Failed
>> dependencies: libGL.so.1 is needed by libglut3-7.11-r13.2.armv6 
>> libGL.so.1 is needed by column-wallboard-1.0-r1.armv6 libGL.so.1 is
>> needed by libglu1-7.11-r13.2.armv6
>> 
>> libGL is showing in the work area, so I think I just need to add a
>> dependency. But what and where?

There should be no GL on RPI at all, the HW drivers only support GLES/2,
so the short answer is you can't pull in packages that require GL (in
theory you could build mesa with the software rasterizer, but you will
get unacceptable performance, and in the presence of GLES2 that makes no
sense anyway).

Incidentally, the GLES libs are not currently packaged by
meta-raspberrypi, I submitted a pull request for this yesterday.


> Ah, there was an ERROR right at the start of the build saying there
> were multiple providers for virtual/libgl (mesa-xlib, mesa-dri). How
> can I track down the cause of this? Building virtual/libgl doesn't
> get this error - it only shows when I build the full image.

In general, mesa-xlib provides a software GLX emulation, mesa-dri
provides glx based on the GLX extension and each machine conf needs to
choose a preferred provider for virtual/libgl to get rid of this error.
However, in the RPI case, no virtual/libgl should be getting pulled into
the images.

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

Re: [yocto] RFC: poky-tiny: init procedure

[Tomas Frydrych]

Hi Darren,

On 14/06/12 22:09, Darren Hart wrote:
> This solution improves the kick-the-tires
> experience with poky-tiny, without pulling in all of init, 

I think you really should quantify what 'all of init' means, without
this you are addressing a problem that is merely perceived. Just a quick
look shows that the sysvinit package is about 120KB unpacked, for that
you get a solution that is tested, robust, and supported across Yocto.


> Again, we're talking about 14 lines of shell, so "init system" is
> overstating it significantly.

Sure, but every new wheel starts exactly this way, and we are already
discussing how to make it do things that sysvinit does for you :-)


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

Re: [yocto] RFC: poky-tiny: init procedure

[Tomas Frydrych]

On 15/06/12 20:49, Tim Bird wrote:
> On 06/14/2012 11:31 PM, Tomas Frydrych wrote:
> IMHO, the whole notion of starting with a big system and
> subtracting what you don't want in order to create a minimal
> system is the wrong approach.

At no point in this discussion was such an approach advocated by anyone.


> I realize you said that with a smiley, so I'm not trying to be
> dismissive or harsh, but I do think that if you want the features
> of some other init system, then the right answer is to use them,
> and not complain about this one.

I am not complaining, I have asked what the specific, quantifiable,
objective of creating the home grown init 'procedure' is, IMHO that is
an entirely reasonable question to an RFC, the answer to which should
inform the design.

If we are talking about targeting 1MB of RAM then it is unavoidable that
the system has to be hand crafted to a fair degree. It is not what I'd
consider the typical Poky use case, but within those constrains, I'd
probably be looking at eliminating shell scripts altogether in my
customization of whatever Poky offers.

Tomas


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

Re: [yocto] RFC: poky-tiny: init procedure

[Tomas Frydrych]

Hi Darren,

On 16/06/12 00:15, Darren Hart wrote:
> I dont think
> Tim's comment was wrong there. Of course "big system" is subjective, to
> me that's anything over 4 MB of storage and 8MB of RAM, for Tim, that's
> 1 MB of RAM.

Indeed, I was thinking of something like the OpenRisc board
(http://opencores.org/shop,item,9), which is a 1MB flash / 32MB RAM,
which I now realize is a huge system by both your and Tim standards :)


> Your point on eliminating shell scripts is a good one though.

In my experience scripts tend show fairly visibly on poky bootchart,
that's all.

I was thinking that for a small system, where I know exactly what I
want, the rc.local file could probably be fairly easily replaced with a
custom config-less spawner written in C. If done with a view to permit
easy modification of the .c source file, it would not be any more hassle
customizing than tweaking a shell script. But you would loose the
ability to tweak config over ssh, which is a significant trade off for
development / debugging, so I think the rc.local is a better default
approach (and alternatives can always be dropped in using the
ALTERNATIVES mechanism anyway).

I think the busybox sysvinit is probably worth experimenting with to get
some idea what size of a system it would be a viable alternative for the
default, and document that somewhere.

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

Re: [yocto] Help needed understanding do_rootfs error

[Tomas Frydrych]

Hi Chris,

On 15/06/12 21:09, Chris Tapp wrote:
> On 15 Jun 2012, at 07:01, Tomas Frydrych wrote:
>> Incidentally, the GLES libs are not currently packaged by 
>> meta-raspberrypi, I submitted a pull request for this yesterday.
> 
> Thanks, that will be nice. I want to look at GLES for other things.
> May even update what I already have if it shows significant
> performance advantages (which it should). Looks like DirectFB has
> some sort of GLES support, so I also need to look at that.

I am aiming to get Clutter working on the RPI, but it looks like bits of
the graphics drivers needed by libEGL are missing :( I opened an issue
for this in github (https://github.com/raspberrypi/firmware/issues/43),
we will see.

Tomas


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

Re: [yocto] how do I prevent a specific package from being built/installed (e.g., bash)?

[Tomas Frydrych]

Hi,

On 16/06/12 17:24, Anders Roxell wrote:
> See subject.
> Is there some config-file for package-masks (like portage's
> /etc/portage/package.mask)?

Packages are getting installed because something depends on them, so if
you want an image that has different contents than one of the default
images, you will need to create your own custom recipe for it.

You can examine the package dependencies with 'bitbake -g -u depexp '; this does not give you any runtime dependencies that are
automatically calculated from shared library deps, but for something
like bash it will give you enough info to know what is pulling it in.

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

Re: [yocto] developing with devshell and effect of the bitbake.conf file

[Tomas Frydrych]

Hi Scott,

On 19/06/12 19:13, Rifenbark, Scott M wrote:
> Hi, I want to throw this out for discussion.  I recently was looking
> at a section in the YP Reference manual
> (http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#platdev-appdev-devshell)
> where it talks about developing using devshell.  I asked Darren Hart
> if this was a valid development model and he says it is.

Absolutely, without devshell poky would be just a distro image builder,
devshell makes into a proper development tool, e.g. devshell is by far
the easiest way to develop/maintain patches (together with quilt) or to
tweak applications when debugging and testing.


> There is a
> part of the section though that talks about the bitbake.conf file.
> That section in the conf file does not seem to exist anymore.  And,
> Darren (after some testing) doesn't see how what is in the
> bitbake.conf file affects development with devshell.  Any comments
> welcome.

I think that bit of the manual is leftover from days of distant past.
The terminal selection it mentions generally happens automatically, but
can be forced by the OE_TERMINAL variable from local.conf, where it is
also documented.

Tomas

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

Re: [yocto] is it "IMAGE_INSTALL +=" or "IMAGE_INSTALL_append ="?

[Tomas Frydrych]

Hi,

On 19/06/12 19:47, Chris Tapp wrote:
> Is there a section that explains the order in which all these things
> happen? i.e. items in local.conf happen before/after...

IIRC, the evaluation orders is:

1. variables on the command line (e.g., 'MACHINE=beagleboard bitbake
myimage') are evaluated first,

2. variables in local.conf,

3. Rest depends on the order of things in bblayers.conf *and* how any
given layer.conf is implemented (some layers preppend their stuff to the
BBPATH and some layers append; from memory the Yocto layers prepend, but
layers from OE usually append, and this inconsistency makes for lot of
fun when combining layers into custom distro).

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

Re: [yocto] the current yocto FAQ is pretty much valueless

[Tomas Frydrych]

On 26/06/12 10:09, Robert P. J. Day wrote:
> A bad Frequently Asked Questions (FAQ) sheet is one that is composed
> not of the questions people actually ask, but of the questions the
> FAQ's author wishes people would ask. Perhaps you've seen the type
> before:

Nice quote, but unfortunately based on the literal meaning the acronym
rather then insight into the function of a FAQ; asking the right
questions is far more important than finding answers ... ;-)


> "how can i use the yocto prebuilt toolchains to save build time?"

Perhaps your question is not asked frequently enough to merit inclusion
in a FAQ, or perhaps it's an a far too advanced topic for a FAQ?


>   a *bad* FAQ would be:
> 
> "Does the Yocto Project have a special governance model, or is it
> managed as an open source project?"

Just because you are not interested in the answer does not make it a
question you should think about ...


>   no, what they ask is, "hey, rob, how can i add a single package to
> an existing target?"  a question that, i should point out, is not
> answered definitively in the existing docs *anywhere*.

There are two correct answers to this: the first one is RTFM; the second
one is that if you want an explicit link to the section of the manual
that explains it to be included in the FAQ, you should write the
appropriate entry for the FAQ and contribute it instead of ranting on
the list.

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

Re: [yocto] the current yocto FAQ is pretty much valueless

[Tomas Frydrych]

On 26/06/12 17:06, Paul Eggleton wrote:
> On Tuesday 26 June 2012 08:46:45 Darren Hart wrote:
>> On 06/26/2012 03:09 AM, Paul Eggleton wrote:
>>> I suggested to Scott R previously that it might be worth having a project
>>> FAQ (i.e., what is this project about, what is it intended to be used for
>>> etc.) and a separate technical FAQ which answers the kind of questions
>>> you are expecting and that we see often on the mailing list. I think one
>>> of the reasons that hasn't been done is that we're hoping to introduce a
>>> Q&A function on the website similar to StackOverflow, where everyone can
>>> participate but the most appropriate answers bubble up to the top. As yet
>>> this has not been implemented and I'm not sure when it will be, so it may
>>> still be worth looking into a static technical FAQ on the wiki until it
>>> is.
>>
>> Is "technical FAQ" == "How-Do-I pages" ?
> 
> Kind of, except most but not all FAQ questions really fit into "How do I...".

Kooen's cheeky point is worth keeping in mind though; the Yocto naming
semantics is not very helpful ;-) Specifically most of the questions
being asked on the Yocto list are about Poky, not Yocto, followed by
questions about meta-yocto, not Yocto-project. Many of the questions
being asked on the list are readily answered by googling for 'Poky
Manual', but clearly very few people understand the Yocto project
semantics enough to do this ...

Tomas


> 
> Cheers,
> Paul
> 

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

Re: [yocto] the current yocto FAQ is pretty much valueless

[Tomas Frydrych]

On 26/06/12 17:53, Robert P. J. Day wrote:
>   and if you want major industry players to take yocto seriously, the
> last thing you want to do is answer their heartfelt pleas for
> assistance with, "i'm sorry, that's technically not a yocto question,
> you should try another mailing list."

That's never been case on this list as far as I recall, folk here are
pretty responsive to questions being asked.

At the same time, OE/Poky/Yocto is a fairly complex framework and nobody
should expect that the necessary expertize to build a commercial grade
products with it can be acquired by simply reading a FAQ, no matter how
well written, or by just endlessly asking questions on a mailing list.
As a commercial player you are either prepared to make the in house
investment that is necessary to acquire that expertize (reading the
documentation and studying the source code, etc.), or you you can buy
the expertize on commercial basis from someone who has it.

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

Re: [yocto] the current yocto FAQ is pretty much valueless

[Tomas Frydrych]

Hi Tim,

On 26/06/12 19:52, Tim Bird wrote:
> On 06/26/2012 10:18 AM, Tomas Frydrych wrote:
> For example, after reading various FAQs
> I still have no idea what kind of thing "Poky" is.  I know
> that bitbake is a build tool.  I know that OE is a package
> meta-information project.  Yocto Project is an umbrella project
> for a lot of tools and technologies (Poky among them).  But is
> Poky a distro (sample/reference or otherwise?) or something else?

For those of us who have been around Poky well before Yocto came around,
we know what Poky used to be, have some inkling what it is, but we are
not always entirely clear what Yocto is. :-)


> When I ran my recently-built image, my target /etc/issue had this content:
> "Yocto (Built by Poky 7.0) 1.2"

My understanding (with the above disclaimer!) is that Poky is a build
system, Yocto is a distro, so I read the above 'Yocto v1.2 image built
by the Poky v7.0 tool'. I think the point of maintaining the distinction
is that you can use Poky without the Yocto Distro (/meta-yocto).

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

Re: [yocto] the current yocto FAQ is pretty much valueless

[Tomas Frydrych]

Hi,

On 26/06/12 18:59, Brian Duffy wrote:
> No, an FAQ should not get you the expertise to create a commercial grade
> product. Reading the documentation should though. You don't want users to
> have to study source code.

If you were paying for the tools, then that would be a reasonable
expectation, but you are not. It is entirely fair to point out that the
documentation is lacking; it is not at all fair to expect that someone
will fix it for you at their own expense. If you are working on a
commercial product, you can, of course, pay someone to improve the
documentation (and even contribute it back to the project).

Also, I think in the Poky context it is better to talk about developers
rather than users; to build a commercial product, your team will need to
have a pretty solid grasp of every aspect of a Linux system.

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

Re: [yocto] LAMP layer

[Tomas Frydrych]

On 27/06/12 16:22, Jack Mitchell wrote:
> Lighttpd (already in core)
> nginx
> Hiawatha (my personal favourite - I have a recipe I already use in
> conjunction with PHP)

I'd add Cherokee to the list; there is a recipe in meta-oe.

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

Re: [yocto] the current yocto FAQ is pretty much valueless

[Tomas Frydrych]

Hi Koen,

On 27/06/12 15:59, Koen Kooi wrote:
> Yocto is NOT a distro. 

Is that so? :-), meta-yocto distro.conf:

DISTRO = "poky"
DISTRO_NAME = "Yocto (Built by Poky 7.0)"
DISTRO_VERSION = "1.2"

I am well aware that textual meaning is pretty much constructed by the
reader, and that authorial intent is an elusive concept, but I am ready
to argue that the conventional understanding of the above is that Poky
is a build tool, and Yocto is the public name of the distro that you
build if you use meta-yocto. To read that as 'Yocto is NOT a distro' I
think requires a definite pre-understanding that Yocto is not a distro,
which would need to come from some other source (or perhaps it is an
axiom of faith; myself, I tend hold firmly to the authority of the
source code alone). I shall not deny you the right to hold to such a
reading, but I do reserve the right to deconstruct it. :-)


> This thread highlights the reason the oe folks have been pushing to get rid 
> of the 'poky' name completely

Perhaps one of the reasons; but then the erasure of Poky would mean that
you could no longer say 'Yocto is a NOT a distro', which I suspect would
achieve the very opposite of what you seek (and, perhaps more
importantly, might cost Dave and Saul a lunch or two). Personally, I
think much better solution would be if the distro was simply called Poky
v7.0, then we could all say 'Yocto is NOT a distro!' with conviction.
Plus Poky is such a lovely name, don't you think? ;-)

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

Re: [yocto] the current yocto FAQ is pretty much valueless

[Tomas Frydrych]

Hi Koen,

On 27/06/12 22:58, Koen Kooi wrote:
> I have no problem with poky-the-distro, I have a problem with
> poky-the-buildsystem. I warned mallum about this confusion years ago,
> but you know how stubborn he can be :)

The Yocto naming confusion is entirely of Yocto making, nothing at all
to do with days of yore. There was never any confusion about what Poky
was before Yocto, just unhappiness of some that Poky was not just a
distro. :)

Poky-the-buildsystem was simply necessary. OE-the-buildsystem is a
wonderful, rich, community project, but one in a constant and
unpredictable flux. This is great for tinkering, but PITA when trying to
develop and long term maintain a product (much bigger problem than what
sparked this thread for sure). In the absence of a clearly defined
process for the OE-the-buildsystem Poky had to bring sanity to the
buildsystem itself and could not be just a distro. It introduced QA,
releases, it focused on facilitating customization and manageable
upgrade paths (and even provided some documentation!).

Yocto is based on Poky; if it was not, it would need to create something
just like Poky (the alternative would be asserting complete control over
OE as a whole, not good I think). OE has benefited from the Poky effort
over the last seven years, and it is a better ecosystem for it. At the
same time, the OE systemd situation (a major system level change without
adequate consideration of the upgrade path) suggests to me that the need
for a sanitized OE-derivative remains.

I shut up now. Really. Maybe. :-)

(Perhaps I should add that I am not formally affiliated with the Yocto
project in any way, my opinions are really my own, not someone else's or
driven by a policy, I have a long history with Poky, so I am definitely
biased in a particular way, I work with Poky on daily basis, and I
tinker with Poky after hours.)

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

Re: [yocto] what's the preferred way of creating images for a classic beagle rev C4?

[Tomas Frydrych]

Hi,

On 08/07/12 19:21, Robert P. J. Day wrote:
>   is it adequate to use the canonical beagleboard support in yocto, or
> should i take advantage of the developments in the meta-ti layer?
> this is for a training course so i don't need production-level
> reliability so much as i want access to as many features as i can get
> for educational purposes.  thanks.

Yocto alone should give you working Sato images; I am fairly certain
that works with Denzil.

If you want/need stuff like accelerated graphics, you have to use
meta-ti, but meta-ti does not play very well with Yocto, so expect to
have to do some tweaking to get things to build. Beyond that, my
experience is that actually getting the meta-ti accelerated video work
is a rather time consuming miss and hit exercise without any guaranteed
results at the end -- if you do not need this for your purposes, then
I'd say don't bother.

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

Re: [yocto] dev manual section on "customizing images" needs serious adjustment

[Tomas Frydrych]

Hi,

On 22/08/12 21:37, Robert P. J. Day wrote:
> One way to get additional software into an image is to create a
> custom image. 

The manual should make it clear that this is *the* canonical way to add
software to your images. Modifications to local.conf are temporary
tweaks for testing/debugging (i.e., you should never feel the need to
commit your local.conf to some project version control system).

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

Re: [yocto] dev manual section on "customizing images" needs serious adjustment

[Tomas Frydrych]

On 24/08/12 16:45, Robert P. J. Day wrote:
> On Fri, 24 Aug 2012, Scott Garman wrote:
> 
>> On 08/23/2012 01:13 AM, Tomas Frydrych wrote:
>>> Hi,
>>>
>>> On 22/08/12 21:37, Robert P. J. Day wrote:
>>>> One way to get additional software into an image is to create a
>>>> custom image.
>>>
>>> The manual should make it clear that this is *the* canonical way to add
>>> software to your images. Modifications to local.conf are temporary
>>> tweaks for testing/debugging (i.e., you should never feel the need to
>>> commit your local.conf to some project version control system).
>>>
>>> Tomas
>>
>> +1. If you add additional packages to core-image-minimal in your local.conf,
>> you're no longer really building core-image-minimal.
> 
>   sure.  but if you similarly explicitly set IMAGE_INSTALL before
> inheriting core-image, you're not really "inheriting" core-image
> either. :-)

That is quite a different thing: core-image-minimal is a recipe to build
an image with defined contents, in contrast core-image is a class, and
the whole point of classes is that recipes can inherit and override them.

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

Re: [yocto] WARNING: QA Issue: udev: /lib/libgudev-1.0.so.0.0.1, installed in the base_prefix, requires a shared library under exec_prefix (/usr)

[Tomas Frydrych]

On 25/08/12 16:29, Andrei Gherzan wrote:
> The obvious fix would be to move libgudev in /usr but before
> doing this we need to be sure that nobody needs this in the early stages of
> booting.

That does not really matter; as things are if something is trying to use
libgudev before /usr is mounted, it will not work anyway, so moving it
under /usr/lib will not break anything that is not already broken per
se. But it could possibly break libgudev itself -- I think this is an
upstream bug that would be best pursued with the udev developers.

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

Re: [yocto] meta-raspberry pi libav bbappend

[Tomas Frydrych]

On 31/08/12 09:44, Jack Mitchell wrote:
> My BBMASK is:
> 
>BBMASK =
>   
> "meta-raspberrypi/recipes-multimedia/libav|meta-raspberrypi/recipes-core/systemd"

I think it matches against full paths, so try:

".*/meta-raspberrypi/recipes-multimedia/libav|.*/meta-raspberrypi/recipes-core/systemd"

Tomas

> 
> 
> 
> 
> Does this BBMASK not cover:
> 
>   
> /home/jack/Projects/poky-rasp/meta-raspberrypi/recipes-multimedia/libav/libav_0.7.4.bbappend
> 
> 
> 
> Cheers,
> 

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

Re: [yocto] meta-raspberry pi libav bbappend

[Tomas Frydrych]

On 31/08/12 10:10, Jack Mitchell wrote:
> Thanks for the suggestion but unfortunately no dice. It was working
> about a week ago with this BBMASK...The only big change I can see is
> that omxplayer now depends in libav, but I have tried just masking the
> whole recipes-multimedia path with the same result, so I don't it's that.


I think the poky-raspberrypi.conf is overriding your BBMASK and it no
longer masks out libav, see
https://github.com/djwillis/meta-raspberrypi/commit/3e0cf999e8fe547a52cb8af28eefdf0f8482daba

Tomas

> 
>>
>>>
>>>
>>>
>>> Does this BBMASK not cover:
>>>
>>>   
>>> /home/jack/Projects/poky-rasp/meta-raspberrypi/recipes-multimedia/libav/libav_0.7.4.bbappend
>>>
>>>
>>>
>>>
>>> Cheers,
>>>
>> ___
>> 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] netbase_4.47.bbappend

[Tomas Frydrych]

Hi,

On 03/09/12 19:03, Raul Rosetto Munoz wrote:
> in my netbase_4.47.bbappend file i have this:
> 
> FILESEXTRAPATHS_prepend := "${THISDIR}/netbase-4.47"

I think you are missing a trailing ':' here, so your path is getting
merged together with whatever is already there (probably the path added
by the bbappend in meta-yocto, i.e., try

FILESEXTRAPATHS_prepend := "${THISDIR}/netbase-4.47:"


> SRC_URI_append  = "file://interfaces"

You don't need this; the base recipe already has this, simply modifying
the FILESEXTRAPATHS is enough.

> do_install_append () {
> install -m 644 ${WORKDIR}/interfaces ${D}/${sysconfdir}/network/
> }

Similarly, you do not needs this either, the base do_install() method
already does this.

But if this interfaces file is for a specific machine, you might want to
consider putting your interfaces file into a machine specific location,
i.e.,

   netbase-4.47//interfaces

This will ensure the interfaces file is only used for that specific
machine (you do not need to make any other changes in the bb file, this
happens by some clever magic automatically); see how this is done in
meta/recipes-core/netbase for the various qemu machines.

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

[yocto] yocto beagleboard.conf -- should it not go away?

[Tomas Frydrych]

Hi,

I am wondering why yocto includes a beagleboard.conf when it is unable
to support much of the board's features, and there is a dedicated layer
for TI stuff that defines the beagleboard machine properly.

I actually have a fairly practical gripe here: it is currently not
possible to include both meta-yocto and meta-ti, and have it use the
correct beagleboard.conf from meta-ti! The meta-yocto layer prepends
itself to the BBPATH while meta-ti appends itself, so regarless the
layer arrangement, the (not-much-useful) yocto beagleboard.conf is
always used, and everything is broken. The only way to work around this
that I can think of is to provide yet another beagleboard.conf from a
custom layer that also preppends itself to the BBPATH, which feels like
three sides of a square route.

So, is there a good reason not to get rid of yocto beagleboard.conf?

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

Re: [yocto] yocto beagleboard.conf -- should it not go away?

[Tomas Frydrych]

Hi,

On 03/09/12 21:15, Bruce Ashfield wrote:
> On Mon, Sep 3, 2012 at 4:06 PM, Tomas Frydrych
> So we fix the configuration of the layers .. 

I expect this is not actually that trivial. I think the only way to do
this is properly is for the layer priorities to be respected by all
files in the layer, not just the bb files. No idea how involved that
change would be, or what the side effects would be.


> and meta-ti was supposed to work properly with meta-yocto last I heard.

If properly means 'out of the box', then no; the two layers can be made
to work together, but it's fairly clear that nobody comprehensively
tests that combination at the moment.


> The meta-yocto layer beagleboard configuration is a hardware ARM reference, 
> that
> uses the linux-yocto kernel (policy and version) and is used for the
> project QA on hardware.

I am all for QA, but in this instance your QA procedure breaks things
for the end user. Could you not just call it something else, e.g.,
yocto-qa-arm-reference.conf?

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

Re: [yocto] Building a Custom Raspberry Pi Image using OpenEmbedded and Yocto

[Tomas Frydrych]

Hi Jack,

On 03/09/12 18:52, Jack Mitchell wrote:
> As some of you know I run a small Raspberry Pi community site[1] and I
> would like to write a follow up to an earlier blog post about preparing
> yourself for programming on the Raspberry Pi with the Yocto Project.

I don't know if of any use to you, but we have a recipe for a
Yocto-based image for a UPnP audio player, which can be built for the
RPi, in Guacamayo[1].

Tomas

[1] https://github.com/Guacamayo/meta-guacamayo

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

Re: [yocto] yocto beagleboard.conf -- should it not go away?

[Tomas Frydrych]

Hi Bruce,

On 03/09/12 22:08, Bruce Ashfield wrote:
> That being said, taking a step back, what are you trying to get out of
> meta-yocto in this scenario ? 

a) I am targeting multiple chips, including TI Omap and Intel Atom.
meta-yocto is a prerequisite for the various machines in meta-intel, so
I have to include meta-yocto if I want to build images for an Intel
chip. Nothing unusual here.

b) meta-yocto is the Poky distro layer; if you want to use Poky, then
you need meta-yocto.

> see above. I misspoke. I don't think there's an intent to make meta-yocto
> and meta-ti work together, but oe-core + meta-ti, that's the combo that
> makes sense.

See (b) above; you are not saying that Poky is only meant for Intel HW,
are you?

The basic problem with meta-yocto is that it combines BSP stuff
(meta-intel prerequisite, Atom & Beagle config) with distro stuff (Poky,
Yocto branding). That's convenient for doing QA on a limited set of HW,
but suboptimal for real use; BSP layers simply should not be dependent
on distro layers, it largely defeats the purpose of having layers.

Splitting out the minimal beagle config into a layer of its own would
improve things quite a bit.

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

Re: [yocto] yocto beagleboard.conf -- should it not go away?

[Tomas Frydrych]

On 04/09/12 21:25, William Mills wrote:
> I suspect the current issue is just growing pains for a case that has
> not been tested.

The simplest fix would be for meta-ti to preppend itself to the path the
same way meta-yocto does, i.e., in the layer.conf

  BBPATH := "${LAYERDIR}:${BBPATH}"

In fact, this is the *only* way that a layer can override any conf files
in oe-core, which is probably what you always want in a BSP layer?

Just quickly scanning yocto git, there are a number of BSP layers that
are configured the same way as meta-ti, so potentially have the same
problem, e.g., meta-intel, meta-fsl-ppc. (There are other generic type
layers configured this way too, but I think it's only a big issue for
BSP layers and distro layers.)

As long as we are mixing layers that do both prepend and append, the
layering will continue to be broken in subtle and hard to identify ways.
I can't think of a practical use case where a layer other than oe-core
might need to append itself to the BBPATH? If there were no genuine need
for layers to append to the path, the BBPATH extension could be done
automatically when including the layer, instead doing manually in each
layer.conf, giving us some consistency.


> Darren: Is it true you can't get @ the Intel BSP's w/o also getting the
> poky distro defs?  That does seem to mixing things a bit.  (I am not
> claiming meta-ti is clean yet but I want to understand the Intel examples.)

I apologize for getting this wrong, meta-intel is not dependent on
meta-yocto (the meta-yocto bbappends are only apply to the machines
meta-yocto itself contains configs for). But you do need meta-yocto for
the atom-pc machine, because meta-yocto is the BSP layer for that (and
should Intel decide to add an atom-pc to meta-intel, it will be broken
exactly the same as the beagleboard machine is just now).

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

Re: [yocto] yocto beagleboard.conf -- should it not go away?

[Tomas Frydrych]

On 05/09/12 10:15, Paul Eggleton wrote:
> On Wednesday 05 September 2012 09:49:11 Tomas Frydrych wrote:
> It has been considered witin OE to be best practice to append to BBPATH and 
> not prepend, the thinking being that then the search path matches the order 
> of 
> the layers listed in bblayers.conf rather than the reverse.

Then meta-yocto should follow that convention ... and it needs to be
well documented, with the consequence of breaking that convention
explained, and the terrible punishments to come described in great and
sordid detail. Because this needs to be more than a convention, it needs
to be an article of faith.

Tomas


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

Re: [yocto] yocto beagleboard.conf -- should it not go away?

[Tomas Frydrych]

On 05/09/12 15:45, William Mills wrote:
>> Its accepted that most layers will append to BBPATH. I do think its
>> acceptable for a distro policy layer to prepend though and this is why
>> meta-yocto does this. I don't remember the exact reason right now but
>> the principle stands.
> 
> So how should we resolve the issue in meta-ti for the denzil/1.2 branch?
> 
> I think the expediency of prepending sounds right to me.  We can shoot
> for a better fix in 1.3.

I think in the light of what Paul said, the meta-ti behaviour is what is
expected and changing will potentially complicate things for other
meta-ti consumers who follow the convention; the problem is in
meta-yocto, not meta-ti.

The current problem can be worked around; it requires a custom layer
that also prepends itself to the path in front of meta-yocto, and then
provides a beagleboard.conf of it's own (which can simply 'include' or
'require' the beagleboard.conf from meta-ti). I think if Richard is
working on a solution in meta-yocto, it might be enough to document this
somewhere until it is ready.

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

Re: [yocto] core-image-minimal linux kernel version

[Tomas Frydrych]

Hi,

On 05/09/12 18:35, James Macon wrote:
> I successfully built core-image-minimal.  I now what to understand how the 
> build determine what linux kernel it will be using because the next step I 
> will want to do is add my own recipe that references my own kernel.  I 
> have not been able to find where the linkage to specific kernel is. Can 
> someone  provide an answer.

The kernel is normally specified in the machine conf file; grep for
PREFERRED_PROVIDER_virtual/kernel.

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

Re: [yocto] core-image-minimal linux kernel version

[Tomas Frydrych]

On 05/09/12 20:03, James Macon wrote:
> I found it but this is only partially the answer. I found 
> PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto" in qemu.inc but there 
> is no recipe for linux-yocto. There are recipes for linux-yocto_3.* , 
> linux-yocto-tiny, and linux-yocto-rt_3*. 
> 
> Somewhere during the build process something is appending to linux-yocto. 
> I will keep looking but if someone knows the answer please respond. 

The part before the '_' is the package name, the part after is is
version. So, linux-yocto, linux-yocto-tiny and linux-yocto-rt are three
different kernels, each of which can have multiple versions at the same
time.

You get automatically the highest available version a package unless the
version is specifically pinned down somewhere (e.g.,
PREFERRED_VERSION_virtual/kernel in the configs or DEFAULT_PREFERENCE in
the recipes themselves).

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

Re: [yocto] raspberrypi image questions

[Tomas Frydrych]

On 05/09/12 22:56, Jack Mitchell wrote:
> On 05/09/2012 22:46, Paul Eggleton wrote:
>> On Wednesday 05 September 2012 12:16:44 Gary Thomas wrote:
>>> I just built Yocto/Poky for the raspberrypi, following the
>>> recent thread on this list.  I noticed that the resulting SD
>>> image is ~4GB, but most of that space seems to be unused:
>>>
>>> $ ssh root@192.168.1.150
>>> Warning: Permanently added '192.168.1.150' (RSA) to the list of
>>> known
>>> hosts. root@192.168.1.150's password:
>>> root@raspberrypi:~# df
>>> Filesystem   1K-blocks  Used Available Use% Mounted on
>>> /dev/root57388 46754  7718  86% /
>>> none 93964   156 93808   0% /dev
>>> /dev/mmcblk0p2   57388 46754  7718  86%
>>> /media/mmcblk0p2
>>> /dev/mmcblk0p1   19400  8928 10472  46%
>>> /media/mmcblk0p1
>>> tmpfs9396456 93908   0%
>>> /var/volatile
>>> tmpfs93964 0 93964   0% /dev/shm
>>> tmpfs93964 0 93964   0% /media/ram
>>> root@raspberrypi:~# cat /proc/partitions
>>> major minor  #blocks  name
>>>
>>>  17903977216 mmcblk0
>>>  1791  19456 mmcblk0p1
>>>  17923885056 mmcblk0p2
>>>
>>> Notice that the physical partition for /dev/mmcblk0p2 is huge but
>>> the file system is only 57MB.
>>>
>>> How can I adjust my build and/or resize the file system to actually
>>> use the rest of the SD card?
>> I suspect a resize2fs call is needed in there. Since the SD card class in
>> meta-raspberrypi was changed to use the actual ext2 rootfs image
>> instead of
>> creating a new one on the fly, this has become an issue. I would
>> suggest filing
>> the issue on the meta-raspberrypi github.
>>
>>> Also, is it possible to just build the SD image much like I do for
>>> other devices like the BeagleBoard, albeit with different contents
>>> in /boot?  Sloshing around 4GB images is rather painful, plus it
>>> takes forever to DD it to the SD card.
>> I must be missing something - do you want the rootfs larger or don't
>> you? If
>> it's expanded it will take up 4GB minus the boot partition size so
>> you're into
>> a large dd again...
>>
>> Cheers,
>> Paul
>>
> 
> I think what he means (or this is what I would like to see ;) ) is a
> boot.tar.gz and a rootfs.tar.gz which can then be extracted straight
> onto the partitions? 

For the rootfs, you can just add IMAGE_FSTYPES += "tar.bz2" somewhere
suitable; I tend to do that for all my images, as it makes it easy to
examine the rootfs contents.

Tomas





Hence only a ~40mb boot write and ~50mb rootfs
> write rather than a 4GB dd slog.
> ___
> 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 beagleboard.conf -- should it not go away?

[Tomas Frydrych]

On 05/09/12 22:46, Richard Purdie wrote:
> On Tue, 2012-09-04 at 09:58 +0100, Tomas Frydrych wrote:
>> Hi Bruce,
>>
>> On 03/09/12 22:08, Bruce Ashfield wrote:
>>> That being said, taking a step back, what are you trying to get out of
>>> meta-yocto in this scenario ? 
>>
>> a) I am targeting multiple chips, including TI Omap and Intel Atom.
>> meta-yocto is a prerequisite for the various machines in meta-intel, so
>> I have to include meta-yocto if I want to build images for an Intel
>> chip. Nothing unusual here.
> 
> Is that really true? What in meta-intel depends on meta-yocto?

No, it is not true; I corrected that erroneous statement earlier in this
thread.


> Effectively this is what we've now done and was always the intention
> (see the Yocto Project compatible criteria).

Yes, that looks like it solves the problem neatly. Now I should be able
to include both meta-yocto and meta-yocto-bsb if I want to.

Tomas

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

Re: [yocto] opengl / libgl / libgles

[Tomas Frydrych]

On 06/09/12 11:00, Andrei Gherzan wrote:
> Hello,
> 
> In DISTRO_FEATURES we have opengl. That is pretty vague and generally we
> don't want to have mesa on machines where there is no libgl but only gles +
> egl. For example if we want to compile something that adds a DEPENDS based
> on DISTRO_FEATURE opengl, this dependency will be added even if there is no
> libgl implemented for that specific machine.
> 
> First idea would be that opengl (gl / gles) are machine related. On the
> other hand opengl can be a DISTRO_FEATURE as we have a software
> implementation - mesa.
> 
> How would you guys see a solution for this? The idea that came into my mind
> was to map opengl to libgl or libgles. Or to both if there is the case.

I think we need both machine and distro features matching the options
here: opengl, gles1, gles2. The machine conf sets the MACHINE_FEATURE
appropriately, the distro conf then sets the distro features based on
intersection of distro policy and what is available on the machine.
Recipes like the xserver use DISTRO_FEATURE to determine how to
configure the package.

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

Re: [yocto] How do you release distros produced with Yocto? How should I?

[Tomas Frydrych]

Hi,

On 02/10/12 17:43, Jerrod Peach wrote:
> I'm also starting to think there might be a better way to handle this with
> Yocto's concept of distros (perhaps have a distro for printer X, and a
> different one for printer Y, each pointing at versions of code that are
> good for the respective printer), but my research so far hasn't given me
> enough information on distros to know if this is a reasonable approach.
>  (I've poked through some of the documentation and the mailing list
> archives.)  So, what do you all do for releasing code?  Does anyone have a
> situation similar to mine?  (I can't imagine I'm unique, but maybe I'm more
> special than I thought.)  Even if you don't have a situation like mine,
> what would you suggest I do for releasing code for our printers?

Sounds to me like your situation implies a single distro + multiple
machines, one for each distinct printer model; you can then specify
revisions on per-machine basis. Whether you specify the machine specific
revisions in the bb files, or whether you pull it together into an
include file is a matter of taste more than anything else I suspect, as
long as everyone knows what the deal is. But I'd advise not to specify
package revisions local.conf, that's really for the developer/user to
tweak, and it should not be stored in vcs, doings so just causes pain.

I use the unified include file in Guacamayo for the packages that we
maintain; this is for convenience, as during the development cycle I use
AUTOREV for these packages, but for an actual release specify the
revisions explicitly and having them all in one place makes this easier
to do and not forget anything. See,
https://github.com/Guacamayo/meta-guacamayo/tree/master/meta-guacamayo/conf/
for how we got it set up.

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

Re: [yocto] How do you release distros produced with Yocto? How should I?

[Tomas Frydrych]

Hi,

On 02/10/12 19:45, Jerrod Peach wrote:
> I don't think that's actually what we want.  The architecture of each
> machine will be the same.  That is, one ASIC will generally be on all the
> printers in a family of products.  I think I actually have one machine +
> multiple distros.  Or, should I really be counting each different printer
> as its own machine?

The fact that the underlying HW is the same can be simply reflected by
having the actual HW-related definitions in a common include file. But
if printer X requires different version of package A from printer Y then
they are really best thought of as different machines -- you can make
packages specific to a machine architecture and then reliably pin the
version, you can't make packages distro-specific (the whole OE/Yocto set
up is built around an implicit premise that any given OE/Yocto instance
is made up of a single 'distro' and many 'machines', so the distro
leaves no mark on the packages).

If all that is different are strictly the VCS revisions, you can use
branching but if someone introduces some other subtle difference, like
printer-X requires --enable-feature-x for package A and printer-Y
requires --disable-feature-x for the same package, then using different
machines is the only option to handle this. If you use branching instead
of distinct machines in this scenario, you will have to maintain
distinct build locations *and* package repositories for each branch, as
there is no way to tell package-A with --enable-feature-x from branch
printer-x from package-A with --disable-feature-x from branch printer-y.

Another reason not to use branches is that this increases the
maintenance burden when making changes to packages that are common
across the branches; from experience even with just a couple of extra
branches folk invariably forget to merge the changes everywhere they
should (or merge them into places they should not).

Using different bb files per printer seems like a good idea until you
try it, but you quickly discover it does not really work. The main
problem here is that now packages further down the line can no longer
depend on package-A, and have to depend on package-A-printer-X instead,
so you will need to have multiple versions of the dependent packages
too, and then of those depending on them, and so on ... You might think
that PROVIDES_virtual/package-A would be an answer here, but that really
only works for distinct machines, so you can specify PREFERRED_PROVIDER
or use COMPATIBLE_MACHINE.


> However, we'll likely have at least a hundred
> packages for which we need to set/manipulate revisions.  I would think that
> would get cumbersome, and in an organization the size of ours (500 or so
> developers across two sites), there's not really going to be one person or
> team who knows what should go in that file for a release.  Moreover, that
> still leaves the problem of all those developers needing to know there are
> at least two places in which their package revisions may be controlled.  Is
> your organization significantly smaller than that or are we doing something
> wrong?

I would agree that in this scenario it would best to maintain the source
revisions in the bb recipes themselves, it keeps people rom stepping on
each others toes and accidentally changing revisions for other packages
(which is easily done in automatic merge-conflict resolution gone wrong).

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

Re: [yocto] The BitBake equivalent of "Hello, World!"

[Tomas Frydrych]

>> Tasks must be Python functions. 
>> 
>>
> No, they can be shell functions too.

Probably worth adding that if you are doing an _append() on a task
function, you have to match the original function type. E.g., if you
want to append a shell snippet to a python task function, you need to do
something like this (from the eglibc recipe):

do_unpack_append() {
bb.build.exec_func('do_move_ports', d)
}

do_move_ports() {
if test -d ${WORKDIR}/${EGLIBC_BRANCH}/ports ; then
rm -rf ${S}/ports
mv ${WORKDIR}/${EGLIBC_BRANCH}/ports ${S}/
fi
}

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

Re: [yocto] Making recipes depend on specific layers

[Tomas Frydrych]

Hi,

On 05/10/12 14:58, Philip Balister wrote:
> I run into problems (typically with BSP layers) where I want the layer
> to build only against oe-core, but I also would like to have recipes
> that depend on other layers. Typically, a "complex" image that uses
> packages built from other layers.

Not sure if I fully understood what you are trying to do, but I'd be
worried about adding yet another dependency dimension to the system as a
whole.

Regarding the problems with coexisting bsp layers, I eventually came to
the conclusion that it's best to avoid parsing any irrelevant bsp layers
altogether. The way we handle this in Guacamayo is to keep the
bsp-related recipes in dedicated directories that can be easily BBMASKed
out:

  recipes-bsp/ti-appends: for recipes related to meta-ti
  recipes-bsp/rpi-appends: for recipes related to meta-raspberrypi

For each machine we support we then have a machine conf that looks like
this (e.g., for beagleboard.conf):

  # source canonical beagleboard.conf from meta-ti
  require ../../../layers/meta-ti/conf/machine/beagleboard.conf

  BBMASK .= "|.*/meta-raspberrypi|.*/recipes-bsp/rpi-appends"

Consequently for any given machine only a single bsp layer is ever
parsed and the layers do not interfere with each other; this currently
triggers a bitbake warning about no recipes being in the masked out
layers, but other than does exactly what it is meant to.

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

Re: [yocto] how to use SECTION in .bb file

[Tomas Frydrych]

On 12/10/12 08:41, Liu wrote:
> Dear all, I want to add some packages to poky,then I faced a question
> : In a recipe there is "SECTION" variable,it is explaned where
> package should be put .But I do not understand what it really
> means.

It's for packages managers to allow them to group common packages
together in the user interface to make it easier to navigate the package
list.

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

[yocto] why was meta-dlna submodule history stripped out?

[Tomas Frydrych]

Looking over meta-dlna in Yocto git I see it's little more than a fork
of meta-guacamayo from guacamayo-project.org -- could someone please
explain to me why the git history was stripped out from this 'combo' layer?

(I am delighted Intel is finding Guacamayo useful, but the obliteration
of the history makes it look as if the credit for this official Yocto
layer goes to Intel; I am sure that was not intentional.)

I am also interested in knowing why the fork was deemed necessary in the
first place, just in case it was for technical reasons that could be
addressed at source.

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

[yocto] why was meta-dlna submodule history stripped out?

[Tomas Frydrych]

Looking over meta-dlna in Yocto git I see it's little more than a fork
of meta-guacamayo from guacamayo-project.org -- could someone please
explain to me why the git history was stripped out from this 'combo' layer?

(I am delighted Intel is finding Guacamayo useful, but the obliteration
of the history makes it look as if the credit for this official Yocto
layer goes to Intel; I am sure that was not intentional.)

I am also interested in knowing why the fork was deemed necessary in the
first place, just in case it was for technical reasons that could be
addressed at source.

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

Re: [yocto] why was meta-dlna submodule history stripped out?

[Tomas Frydrych]

Hi Saul

On 19/10/12 19:01, Saul Wold wrote:
> My apologies, I updated the MAINTAINER and README files.

Thanks.

>> (I am delighted Intel is finding Guacamayo useful, but the obliteration
>> of the history makes it look as if the credit for this official Yocto
>> layer goes to Intel; I am sure that was not intentional.)
>>
> No this was not intentional, the combo-layer tool seems to do that. I
> used combo layer because we wanted to pull in the kvm changes so that
> this could be shown as a VM.

Well, Poky uses the combo-layer and it maintains the commit history,
even nicely injects the original hashes into the commit messages for
reference. My basic gripe is that the 'Initial meta-dlna creation'
commit squashes some 370+ commits, which represent somewhere in the
region 500 man hours, bulk of it by sleep(5) ltd. I'd prefer if a public
layer in a Linux Foundation collaborative project did not do away with that.


> In the first pass, there were mostly minor changes to cut this down to
> what was needed for the headless media server.

This is the bit I don't get; it's not like oe-core contains just what is
needed for poky-tiny, but I don't see you creating an oe-core fork for
it. In fact this makes so little sense I doubt it was an engineering
decision, perhaps someone somewhere forgot to take their NIH pills? :)


> As I moved to 1.3 there
> were more changes that I have made, you can see what's going on in the
> 1.3wip branch of meta-dlna. 

You are already getting bitten by the fact that you are forking
meta-guacamayo. Upstream master has been updated to work with 1.3 some
time back. It took fair amount of work to do (more than I'd have
expected; lot of work to get things to build, and then quite a bit more
to get them work).


> If you want some of those changes in meta-guacamayo please take them.

Why is Intel so crap at working with upstream projects? I'll happily
take any meaningful contributions (that excludes adding
MACHINE_FEATURES='x86' into the layer.conf, though!), but please submit
them.


> Right now I am fighting a dbus/rygel segfault.

I am pretty sure I know which one, you are welcome to update to upstream
meta-guacamayo, forks really are not a cost-efficient way of doing things.

Kind regards,

Tomas


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

Re: [yocto] why was meta-dlna submodule history stripped out?

[Tomas Frydrych]

On 20/10/12 13:16, Paul Eggleton wrote:
> On Friday 19 October 2012 11:01:09 Saul Wold wrote:
> Long term however I'd rather see the additional unique recipes in meta-
> guacamayo itself go into more official OE community layers.

Ah, so there is an official community and an unoffical one, this
community stuff is becoming rather difficult. ;-)

I don't have any objections in principle, in fact you will see that
number of the recipes in meta-guacamayo consists of a generic recipe and
a guacamayo-specific bbappend. The main reason for maintaining most of
the recipes in meta-guacamayo is precisely so that they would be
maintained and updated in timely fashion and work with the stable
release of Yocto. Guacamayo aims to facilitate that.

Tomas


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