Date   

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

Jegan Chandru <pcjegan@...>
 

Hi Amit,

where u can add the packages u need in ur image.

core-image-sato is a full linux system with GUI, it is obvious that the size will be somewhat big.
About the image size, it really depends on what package system are you using(rpm, deb, ipk)
If its rpm, the size would be big for a filesystem, and ipk would have the smallest size.

-JC




On Sat, Aug 17, 2013 at 11:24 AM, Amit Kumar <Amit.Kumar@...> wrote:

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.khem@...]
Sent: Wednesday, August 14, 2013 11:37 AM
To: Amit Kumar
Cc: yocto@...
Subject: Re: [yocto] Build packages-ssh,telnet,alsa and other package for arm

 

 

On Aug 13, 2013, at 10:49 PM, Amit Kumar <Amit.Kumar@...> 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

 

 

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@...
https://lists.yoctoproject.org/listinfo/yocto

 


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




--
JCP


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

Amit Kumar <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.khem@...]
Sent: Wednesday, August 14, 2013 11:37 AM
To: Amit Kumar
Cc: yocto@...
Subject: Re: [yocto] Build packages-ssh,telnet,alsa and other package for arm

 

 

On Aug 13, 2013, at 10:49 PM, Amit Kumar <Amit.Kumar@...> 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

 

 

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@...
https://lists.yoctoproject.org/listinfo/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
Paul mailto:pderocco@ix.netcom.com


Re: Full Screen Image Display Program

Paul Barker <paul@...>
 

On 16 August 2013 15:48, Wenholz, Brian (GE Healthcare)
<Brian.Wenholz@med.ge.com> 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: paul@paulbarker.me.uk
http://www.paulbarker.me.uk


Re: 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
Paul mailto:pderocco@ix.netcom.com


Re: 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-bounces@... [mailto:yocto-bounces@...] On Behalf Of Alagarsamy, Siva
Sent: Friday, August 16, 2013 9:14 AM
To: yocto@...
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


Using boost in the cross compiler environment

Alagarsamy, Siva <siva.alagarsamy@...>
 

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


Full Screen Image Display Program

Wenholz, Brian (GE Healthcare) <Brian.Wenholz@...>
 

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


Re: My stuff is missing from rootfs

Mark Hatle <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 <image>, 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


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

mulhern <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 <mulhern@yoctoproject.org>
---
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


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

mulhern <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 <mulhern@yoctoproject.org>
---
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


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

mulhern <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


Re: 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 <gary@...> 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: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@...
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.boto@...
=============================================


Re: 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
------------------------------------------------------------


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

Paul Barker <paul@...>
 

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 <paul@paulbarker.me.uk>
---
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


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

Paul Barker <paul@...>
 

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: paul@paulbarker.me.uk
http://www.paulbarker.me.uk


Re: 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


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

mulhern <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 <mulhern@yoctoproject.org>
---
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..c05ae1e 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 small 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


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

mulhern <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 <mulhern@yoctoproject.org>
---
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


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

mulhern <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-final4
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=mulhern/bug4916-final4

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