Re: [yocto] Build packages-ssh, telnet, alsa and other package for arm

[Amit Kumar]

Hi Raj,
Thanks for the suggestion, I have built the image as 
"core-image-base" , now I got the ssh, sftp working with my image.
But some more packages I need like- gtk+, I have taken those packages using the 
"hob" and build the image "bitbake core-image-base",
But when I check that image using QEMU the "libgtk" does not present. I am not 
able to test or run my gtk app in QEMU.

How do I get it in my image. If I build core-image-sato the libgtk present and 
I can test my app, but the image size is too big.
Is there anyway either reduce the image-sato size or include the gtk support in 
core-image-base?


Thanks & Regards
Amit K

From: Khem Raj [mailto:raj.k...@gmail.com]
Sent: Wednesday, August 14, 2013 11:37 AM
To: Amit Kumar
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Build packages-ssh,telnet,alsa and other package for arm


On Aug 13, 2013, at 10:49 PM, Amit Kumar 
mailto:amit.ku...@lntinfotech.com>> wrote:


Hi,

Using the Yocto Project 1.4, I want to build the packages like ssh, 
telnet, alias and other library packages for arm. I am not getting an idea how 
I should have to add those packages in my build environment. I want to build 
them and test, using the QEMU, is that possible? I want to build them for arm.


You can start by building a reference image e.g. core-image-basic and then add 
the packages as you want extra I would encourage to read through the
manual

https://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html

especially IMAGE_FEATURES and IMAGE_INSTALL and CORE_IMAGE_EXTRA_INSTALL 
variables.





Thanks & Regards
Amit K


The contents of this e-mail and any attachment(s) may contain confidential or 
privileged information for the intended recipient(s). Unintended recipients are 
prohibited from taking action on the basis of information in this e-mail and 
using or disseminating the information, and must notify the sender and delete 
it from their system. L&T Infotech will not accept responsibility or liability 
for the accuracy or completeness of, or the presence of any virus or disabling 
code in this e-mail"
___
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] bbappend on top of bbappend

[Paul D. DeRocco]

In meta-oe/recipes-graphics/xinput-calibrator (Danny branch, currently
used by Gumstix), there's a recipe called xinput-calibrator-git.bb, which
installs a script for running a touchscreen calibration app if not already
calibrated.

In
meta-openembedded/meta-systemd/meta-oe/recipes-graphics/xinput-calibrator,
there's a bbappend for this recipe, which declares a local file called
xinput-calibrator.service, which is supposed to run the above script on
startup. It inherits the systemd bbclass, which I assume knows how to
install this service file automagically, since there's no explicit
do_install copying the file anywhere.

The trouble is, on my Gumstix, the service fails because it needs a
DISPLAY environment variable to tell it what display to calibrate. I
figured the simplest thing to do would be to add an Environment=DISPLAY=:0
line to the service unit file.

My shameless hack was to add a ROOTFS_POSTPROCESS_COMMAND that runs sed on
the final copy of this service file in the rootfs, to insert the
Environment= line, and that works. But I'd rather just provide my own
version of the file, and use another .bbappend to prepend its file
location to FILESEXTRAPATHS, overriding the one in the systemd .bbappend
file.

So I tried that, just putting the following two lines into my own
.bbappend:

FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
PRINC := "${@int(PRINC) + 1}"

and of course putting the tweaked service file into my files subdirectory.
On starting the build, it almost immediately spat this out:

NOTE:
['/home/pauld/yocto/meta-foo/recipes/xinput-calibrator_git.bbappend',
'/home/pauld/yocto/poky/meta-openembedded/meta-systemd/meta-oe/recipes-gra
phics/xinput-calibrator/xinput-calibrator_git.bbappend'] to
['/home/pauld/yocto/poky/meta-openembedded/meta-systemd/meta-oe/recipes-gr
aphics/xinput-calibrator/xinput-calibrator_git.bbappend']

(That was all on one line, of course.)

The do_rootfs failed, and its log says that xinput-calibrator is an
unknown package, and that it can't satisfy the dependency from
packagegroup-core-x11-base.

I read somewhere that stacked bbappends are handled in the order of layer
priority. Mine is 5, the meta-systemd layer is 7. I don't know which is
"higher", or if one wants a higher or lower priority in order to be the
last one to prepend to the path. But somehow, I think my problem is a
little more fundamental.

Can anyone give me a little guidance here?

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com 
 

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

Re: [yocto] Full Screen Image Display Program

[Paul Barker]

On 16 August 2013 15:48, Wenholz, Brian (GE Healthcare)
 wrote:
> Does anyone have, or can point me to, a good recipe for qiv that will work
> with Yocto 1.3?
>

It isn't found on layers.openembedded.org so it's probably not in any
of the major layers. It should be too complicated a program to write a
recipe for though. I tend to look to Arch Linux for inspiration and to
see if any extra patches are needed:
https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/qiv.
The syntax is different but you can see their dependencies, the lack
of any custom patches and the fact that you just need to ensure that
'make' is called then copy the resulting binary and man page.

Have you written your own recipes before?

-- 
Paul Barker

Email: p...@paulbarker.me.uk
http://www.paulbarker.me.uk
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] My stuff is missing from rootfs

[Paul D. DeRocco]

> From: Paul Eggleton
> 
> You didn't mention in your reply to Saul whether the foo 
> package was mentioned 
> in log.do_rootfs or installed_pkgs.txt files in your old 
> tmpdir; was it?

It's in both places. Yet NONE of the various files that were supposed to
be part of that recipe ended up in the rootfs, after several tries, even
though the logs showed that recipe being built.

I think the problem may have been caused by once hitting Ctrl-C at the
beginning of do_rootfs, because I remembered that I had to tweak one of
the files, and I didn't want to wait the fifteen minutes for that to
complete. (I'm running on an Atom.) As it happens, Ctrl-C just sets a flag
that interrupts the process after the task completes, so it didn't really
help, but I think that's when the problem started. Maybe that's a clue.

> > That said, rebuilding tmp (preserving downloads and 
> > sstate-cache) did
> > indeed fix that problem, but it was replaced with another. 
> > Now, do_rootfs
> > is failing, complaining that it "cannot satisfy the 
> > following dependencies
> > for samba: libpam (>= 1.1.6)". Yet there's libpam, version 
> > 1.1.6, right
> > where it's always been in the metadata. Doing a clean and a 
> > cleansstate on
> > libpam didn't help. 
> 
> Does samba.inc used by the samba recipe you are building have 
> a PACKAGECONFIG 
> line referring to pam? I think that was added recently in 
> meta-oe master (and 
> shortly to be merged into the meta-oe dylan branch). Without 
> it there will be 
> a floating dependency on pam, which may account for this latter issue.

No, it's not mentioned in samba.inc, samba-basic.inc or in the recipe
itself.

And cleaning samba and rebuilding fixed the problem. So I suspect what's
been done in the Dylan branch has dealt with that problem, and for now
everything in the Danny branch works fine as long as things get done in
the normal order.

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com 

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

Re: [yocto] Using boost in the cross compiler environment

[Zhang, Jessica]

Hi Siva,

 

1st Follow the developer manual to add boost library to your image.  Then do
"bitbake your-image-with-boost -c populate_sdk", it'll generate a SDK
tarball for you that contains cross toolchain and the sysroot that contains
the boost library, which allows you to cross develop your user application.

 

Cheers,

Jessica

 

From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org]
On Behalf Of Alagarsamy, Siva
Sent: Friday, August 16, 2013 9:14 AM
To: yocto@yoctoproject.org
Subject: [yocto] Using boost in the cross compiler environment

 

I am new to the Yocot.  I have was able succesffuly build a poky image for a
development board.  I was able to generate a adt-installer using "bitbake
adt-installer" command.  I am able to compile a simple hello world program
and run it on the development board. I need to use "Boost" library in my
user application. What is the proper procedure to install the boost in my
cross compiler environment? 


Thanks,
Siva



smime.p7s
Description: S/MIME cryptographic signature
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Using boost in the cross compiler environment

[Alagarsamy, Siva]

I am new to the Yocot.  I have was able succesffuly build a poky image for a 
development board.  I was able to generate a adt-installer using "bitbake 
adt-installer" command.  I am able to compile a simple hello world program and 
run it on the development board. I need to use "Boost" library in my user 
application. What is the proper procedure to install the boost in my cross 
compiler environment?

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

[yocto] Full Screen Image Display Program

[Wenholz, Brian (GE Healthcare)]

Does anyone have, or can point me to, a good recipe for qiv that will work with 
Yocto 1.3?

I found an obsolete qiv recipe via openembedded, but to update it will be 
basically writing a new recipe since the source locations and dependencies have 
changed.

I am open to other suggestions to meet my needs as well. I need a program that 
will:
-Display PNG images in full screen mode
-Display the image without overlays
-Display to the X server (I do not have a user space accessible frame buffer 
device)
-Operate from the command line or a shell script

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

Re: [yocto] My stuff is missing from rootfs

[Mark Hatle]

On 8/15/13 7:20 PM, Paul D. DeRocco wrote:

From: Mark Hatle

A simple way to diagnose if your package is even in the
install list is to do
bitbake -e , then scan the output for
"PACKAGE_INSTALL".  If your package
is not listed there, then something has either cleared your
configuration or you
have a typo.

IMAGE_INSTALL_append = " my_package" should work, and
generally won't be cleared
by a recipe.


It's there, and it's all working now. I've had things break in odd ways
before, and recover when I rebuilt. This time it took a couple of tries.

What makes it frustrating is that I'm building on a wimpy Atom system.
I've been on the verge of buying a killer system just to do builds, but I
keep thinking, maybe I'll only need to do this another dozen or so times
and then I'll be done, in which case it wouldn't be a good investment.


(Note you should modify IMAGE_INSTALL, which is transformed
by the system into
PACKAGE_INSTALL... modifying PACKAGE_INSTALL can lead to problems.)


I don't think that all the various ways to append stuff will ever make
sense to me. Currently, I'm using IMAGE_INSTALL += "..." in my top level
recipe, and it works. I don't know what IMAGE_INSTALL_append does
differently.



Difference between IMAGE_INSTALL += and IMAGE_INSTALL_append is when the process 
happens.


IMAGE_INSTALL += happens immediately, and if something later in the resolution 
does "IMAGE_INSTALL = " then you can lose the value.


IMAGE_INSTALL_append happens at the very end of variable resolution.. i.e.:

IMAGE_INSTALL_append = " mypkg"
IMAGE_INSTALL = "foo"
IMAGE_INSTALL += "bar"
IMAGE_INSTALL = "foobar"

Your end result will be "foobar mypkg"...

(USUALLY the '=' in the example above actually indicates a bug of some kind.. 
but it does happen.)


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

[yocto] [PATCH 1/2] curses-perl: Change description to match package.

[mulhern]

[YOCTO #4196] -- https://bugzilla.yoctoproject.org/show_bug.cgi?id=4196

The description field in the recipe was changed to match the package.

Signed-off-by: mulhern 
---
 recipes-security/perl/curses-perl_1.28.bb |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/recipes-security/perl/curses-perl_1.28.bb 
b/recipes-security/perl/curses-perl_1.28.bb
index 5984ca7..d05a0f2 100644
--- a/recipes-security/perl/curses-perl_1.28.bb
+++ b/recipes-security/perl/curses-perl_1.28.bb
@@ -1,6 +1,5 @@
-DESCRIPTION = "This package contains the URI.pm module with friends. \
-The module implements the URI class. URI objects can be used to access \
-and manipulate the various components that make up these strings."
+DESCRIPTION = "lib-curses provides an interface between Perl programs and \
+the curses library."
 
 SECTION = "libs"
 LICENSE = "Artistic-1.0 | GPL-1.0+"
-- 
1.7.10.4

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

[yocto] [PATCH 0/2] [meta-security] Change descriptions to match packages.

[mulhern]

This patch changes the description field to match the package.
The following changes since commit 4f2821cb7b01ca11249154d1d071bc267dbf4f85:

  removed rpm dependency on redhat-security (2013-08-01 12:16:29 +0300)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib mulhern/bug4916-final5
  
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=mulhern/bug4916-final5

mulhern (2):
  curses-perl: Change description to match package.
  lib-perl: Change description to match package.

 recipes-security/perl/curses-perl_1.28.bb |5 ++---
 recipes-security/perl/lib-perl_0.63.bb|7 ---
 2 files changed, 6 insertions(+), 6 deletions(-)

-- 
1.7.10.4

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

[yocto] [PATCH 2/2] lib-perl: Change description to match package.

[mulhern]

[YOCTO #4196] -- https://bugzilla.yoctoproject.org/show_bug.cgi?id=4196

The description field in the recipe was changed to match the package.

Signed-off-by: mulhern 
---
 recipes-security/perl/lib-perl_0.63.bb |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/recipes-security/perl/lib-perl_0.63.bb 
b/recipes-security/perl/lib-perl_0.63.bb
index 606ecfb..0696382 100644
--- a/recipes-security/perl/lib-perl_0.63.bb
+++ b/recipes-security/perl/lib-perl_0.63.bb
@@ -1,6 +1,7 @@
-DESCRIPTION = "This package contains the URI.pm module with friends. \
-The module implements the URI class. URI objects can be used to access \
-and manipulate the various components that make up these strings."
+DESCRIPTION = "This is a simple module which simplifies the \
+manipulation of @INC at compile time. It is typically used to add extra \
+directories to Perl's search path so that later 'use' or 'require' statements \
+will find modules which are not located in the default search path."
 
 SECTION = "libs"
 LICENSE = "Artistic-1.0 | GPL-1.0+"
-- 
1.7.10.4

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

Re: [yocto] systemd support?

[Erik Botö]

Hi,

There's a bug in the bugzilla for this,
https://bugzilla.yoctoproject.org/show_bug.cgi?id=4843 . You can also look
at a mail thread,
http://lists.openembedded.org/pipermail/openembedded-core/2013-June/080328.html
for
some more context.

If you just want to get past it you can do something like the below. It's
not a real fix but a work around.

diff --git a/meta/classes/qemu.bbclass b/meta/classes/qemu.bbclass
index 3d437b0..0f6e882 100644
--- a/meta/classes/qemu.bbclass
+++ b/meta/classes/qemu.bbclass
@@ -30,6 +30,6 @@ def qemu_run_binary(data, rootfs_path, binary):
 libdir = rootfs_path + data.getVar("libdir", False)
 base_libdir = rootfs_path + data.getVar("base_libdir", False)
-return "PSEUDO_UNLOAD=1 " + qemu_binary + " -L " + rootfs_path\
+return "PSEUDO_UNLOAD=1 " + qemu_binary + " -U LD_PRELOAD -L " +
rootfs_path\
 + " -E LD_LIBRARY_PATH=" + libdir + ":" + base_libdir + " "\
 + rootfs_path + binary


Cheers,
Erik Botö



On Fri, Aug 16, 2013 at 1:07 PM, Gary Thomas  wrote:

> On 2013-08-15 16:29, Gary Thomas wrote:
>
>> I tried to take my existing Poky/Yocto system (using my own $DISTRO
>> which is a derivative of poky) and enable systemd.  I'm using today's
>> master:
>>meta  = "cutting-edge:**ff10f72abda52315b892c64f711096**
>> 772d9a4c1c"
>>
>> Sadly, building the simplest image fails with this error:
>>
>> | update-alternatives: Linking /local/p60_systemd/tmp/work/**
>> cobra3530p60-amltd-linux-**gnueabi/amltd-console-image/1.**0-r0/rootfs//sbin/poweroff
>> to /sbin/poweroff.sysvinit
>> | update-alternatives: Linking /local/p60_systemd/tmp/work/**
>> cobra3530p60-amltd-linux-**gnueabi/amltd-console-image/1.**0-r0/rootfs//usr/bin/last
>> to /usr/bin/last.sysvinit
>> | update-alternatives: Linking /local/p60_systemd/tmp/work/**
>> cobra3530p60-amltd-linux-**gnueabi/amltd-console-image/1.**0-r0/rootfs//usr/bin/mesg
>> to /usr/bin/mesg.sysvinit
>> | update-alternatives: Linking /local/p60_systemd/tmp/work/**
>> cobra3530p60-amltd-linux-**gnueabi/amltd-console-image/1.**0-r0/rootfs//usr/bin/utmpdump
>> to /usr/bin/utmpdump.sysvinit
>> | update-alternatives: Linking /local/p60_systemd/tmp/work/**
>> cobra3530p60-amltd-linux-**gnueabi/amltd-console-image/1.**0-r0/rootfs//usr/bin/wall
>> to /usr/bin/wall.sysvinit
>> | ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be
>> preloaded: ignored.
>> |  Adding system startup for /local/p60_systemd/tmp/work/**
>> cobra3530p60-amltd-linux-**gnueabi/amltd-console-image/1.**
>> 0-r0/rootfs/etc/init.d/**systemd-udevd.
>> | update-alternatives: Linking /local/p60_systemd/tmp/work/**
>> cobra3530p60-amltd-linux-**gnueabi/amltd-console-image/1.**0-r0/rootfs//usr/bin/scp
>> to /usr/sbin/dropbearmulti
>> | update-alternatives: Linking /local/p60_systemd/tmp/work/**
>> cobra3530p60-amltd-linux-**gnueabi/amltd-console-image/1.**0-r0/rootfs//usr/bin/ssh
>> to /usr/sbin/dropbearmulti
>> |  Adding system startup for /local/p60_systemd/tmp/work/**
>> cobra3530p60-amltd-linux-**gnueabi/amltd-console-image/1.**
>> 0-r0/rootfs/etc/init.d/**dropbear.
>> |  Adding system startup for /local/p60_systemd/tmp/work/**
>> cobra3530p60-amltd-linux-**gnueabi/amltd-console-image/1.**
>> 0-r0/rootfs/etc/init.d/**networking.
>>
>> I wasn't sure what brought in the error so I pasted a number of lines
>> of context.
>>
>> Note: building the same image with 'sysvinit' in DISTRO_FEATURES
>> instead of 'systemd' works fine.
>>
>> Any ideas what's going on here?
>>
>>
> Interesting - this seems to be a host bug.  I got the above error
> when building on Ubuntu 12.04/x86_64.  I do not get the error when
> using Fedora 13/i386.  I've not yet tried any other host.
>
>
> --
> --**--
> Gary Thomas |  Consulting for the
> MLB Associates  |Embedded world
> --**--
> __**_
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.**org/listinfo/yocto
>



-- 
=
Erik Botö
Senior Software Engineer
Pelagicore AB
Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden
Mobile: +46 (0)76 881 72 03
E-Mail: erik.b...@pelagicore.com
=
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] systemd support?

[Gary Thomas]

On 2013-08-15 16:29, Gary Thomas wrote:

I tried to take my existing Poky/Yocto system (using my own $DISTRO
which is a derivative of poky) and enable systemd.  I'm using today's
master:
   meta  = "cutting-edge:ff10f72abda52315b892c64f711096772d9a4c1c"

Sadly, building the simplest image fails with this error:

| update-alternatives: Linking 
/local/p60_systemd/tmp/work/cobra3530p60-amltd-linux-gnueabi/amltd-console-image/1.0-r0/rootfs//sbin/poweroff
 to /sbin/poweroff.sysvinit
| update-alternatives: Linking 
/local/p60_systemd/tmp/work/cobra3530p60-amltd-linux-gnueabi/amltd-console-image/1.0-r0/rootfs//usr/bin/last
 to /usr/bin/last.sysvinit
| update-alternatives: Linking 
/local/p60_systemd/tmp/work/cobra3530p60-amltd-linux-gnueabi/amltd-console-image/1.0-r0/rootfs//usr/bin/mesg
 to /usr/bin/mesg.sysvinit
| update-alternatives: Linking 
/local/p60_systemd/tmp/work/cobra3530p60-amltd-linux-gnueabi/amltd-console-image/1.0-r0/rootfs//usr/bin/utmpdump
 to /usr/bin/utmpdump.sysvinit
| update-alternatives: Linking 
/local/p60_systemd/tmp/work/cobra3530p60-amltd-linux-gnueabi/amltd-console-image/1.0-r0/rootfs//usr/bin/wall
 to /usr/bin/wall.sysvinit
| ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded: 
ignored.
|  Adding system startup for 
/local/p60_systemd/tmp/work/cobra3530p60-amltd-linux-gnueabi/amltd-console-image/1.0-r0/rootfs/etc/init.d/systemd-udevd.
| update-alternatives: Linking 
/local/p60_systemd/tmp/work/cobra3530p60-amltd-linux-gnueabi/amltd-console-image/1.0-r0/rootfs//usr/bin/scp
 to /usr/sbin/dropbearmulti
| update-alternatives: Linking 
/local/p60_systemd/tmp/work/cobra3530p60-amltd-linux-gnueabi/amltd-console-image/1.0-r0/rootfs//usr/bin/ssh
 to /usr/sbin/dropbearmulti
|  Adding system startup for 
/local/p60_systemd/tmp/work/cobra3530p60-amltd-linux-gnueabi/amltd-console-image/1.0-r0/rootfs/etc/init.d/dropbear.
|  Adding system startup for 
/local/p60_systemd/tmp/work/cobra3530p60-amltd-linux-gnueabi/amltd-console-image/1.0-r0/rootfs/etc/init.d/networking.

I wasn't sure what brought in the error so I pasted a number of lines
of context.

Note: building the same image with 'sysvinit' in DISTRO_FEATURES
instead of 'systemd' works fine.

Any ideas what's going on here?



Interesting - this seems to be a host bug.  I got the above error
when building on Ubuntu 12.04/x86_64.  I do not get the error when
using Fedora 13/i386.  I've not yet tried any other host.

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

[yocto] [meta-raspberrypi][PATCH] sdcard_image-rpi.bbclass: Allow optional compression

[Paul Barker]

Image files will typically contain lots of null blocks and should compress well.
This will help with distribution of images over slow network links.

Signed-off-by: Paul Barker 
---
 classes/sdcard_image-rpi.bbclass | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/classes/sdcard_image-rpi.bbclass b/classes/sdcard_image-rpi.bbclass
index a2fcd52..8d2a5f2 100644
--- a/classes/sdcard_image-rpi.bbclass
+++ b/classes/sdcard_image-rpi.bbclass
@@ -50,6 +50,11 @@ IMAGE_DEPENDS_rpi-sdimg = " \
 # SD card image name
 SDIMG = "${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.rpi-sdimg"
 
+# Compression method to apply to SDIMG after it has been created. May be 
"none",
+# "gzip", "bzip2" or "xz". Setting this to something other than "none" will
+# cause SDIMG to be renamed.
+SDIMG_COMPRESSION ?= "none"
+
 # Additional files and/or directories to be copied into the vfat partition 
from the IMAGE_ROOTFS.
 FATPAYLOAD ?= ""
 
@@ -107,6 +112,19 @@ IMAGE_CMD_rpi-sdimg () {
else
dd if=${SDIMG_ROOTFS} of=${SDIMG} conv=notrunc seek=1 bs=$(expr 
1024 \* ${BOOT_SPACE_ALIGNED} + ${IMAGE_ROOTFS_ALIGNMENT} \* 1024) && sync && 
sync
fi
+
+   # Optionally apply compression
+   case "${SDIMG_COMPRESSION}" in
+   "gzip")
+   gzip -9 "${SDIMG}"
+   ;;
+   "bzip2")
+   bzip2 -9 "${SDIMG}"
+   ;;
+   "xz")
+   xz "${SDIMG}"
+   ;;
+   esac
 }
 
 ROOTFS_POSTPROCESS_COMMAND += " rpi_generate_sysctl_config ; "
-- 
1.8.3.4

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

[yocto] [opkg-utils] Splitting package feed directories and where to send patches

[Paul Barker]

I'm planning a patch to opkg-utils to add an option to split packages
into subdirectories in the same way as debian package feeds are often
laid out. So you'd have 'a*' in a subdirectory 'a', 'b*' in 'b', etc.
Packages beginning with 'lib' are put in 'liba', 'libb', etc as
appropriate and packages matching 'l*' but not 'lib*' stay in 'l'.
That's done to reduce the number of files in a single directory - I'm
having trouble mirroring over 7000 files in one directory to my
webserver. I shan't be changing the default, just want to add the
option if I can and then add a way of enabling this behaviour in a
distro config or local.conf.

However, I can't see any info on where to send packages for opkg-utils
and if there's a particular maintainer I need to CC on my emails. I'm
guessing they probably go to this list or someone on this list. So I'm
also going to propose adding a README file to opkg-utils with info on
who's maintaining it and where to send patches.

I now seem to be the de-facto maintainer of opkg itself so it would
make sense for me to co-ordinate with whoever is looking after
opkg-utils.

Thanks,

-- 
Paul Barker

Email: p...@paulbarker.me.uk
http://www.paulbarker.me.uk
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] My stuff is missing from rootfs

[Paul Eggleton]

On Thursday 15 August 2013 15:38:37 Paul D. DeRocco wrote:
> > On Thursday 15 August 2013 13:01:54 Paul D. DeRocco wrote:
> > > This smells like one of those situations where nuking tmp
> > > and rebuilding will fix it, and we'll never know what was wrong. I'll let
> > > you know if that fixes it.
> > 
> > If you keep on doing this we'll never figure out what the
> > problem is. Wiping out tmp just removes any way we might have to diagnose
> > the issue.
> 
> I didn't wipe it out, I renamed it to something else, so I can switch back
> to it if I need to. 

Apologies, I just assumed that's what you meant by "nuking". If there's a bug 
or otherwise undesirable behaviour that is causing this problem I'd really 
like to figure out what it is so we can fix it for everyone.

> I certainly don't have the faintest idea about how to
> diagnose it, beyond the naive steps I've already taken. And I need to get
> back to my real job, which is writing apps for this system, instead of
> building the distro. If there's anything you can think of that I should
> try, I'd be happy to do so.

You didn't mention in your reply to Saul whether the foo package was mentioned 
in log.do_rootfs or installed_pkgs.txt files in your old tmpdir; was it?

> That said, rebuilding tmp (preserving downloads and sstate-cache) did
> indeed fix that problem, but it was replaced with another. Now, do_rootfs
> is failing, complaining that it "cannot satisfy the following dependencies
> for samba: libpam (>= 1.1.6)". Yet there's libpam, version 1.1.6, right
> where it's always been in the metadata. Doing a clean and a cleansstate on
> libpam didn't help. 

Does samba.inc used by the samba recipe you are building have a PACKAGECONFIG 
line referring to pam? I think that was added recently in meta-oe master (and 
shortly to be merged into the meta-oe dylan branch). Without it there will be 
a floating dependency on pam, which may account for this latter issue.

Cheers,
Paul

-- 

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