[yocto] Automatic Upgrade Helper Announcement
Hi all, I'm glad to announce the enabling of Automatic Upgrade Helper (a.k.a. AUH), the AUH is a service that provides recipe upgrades and will be run on weekly basis. If you are a maintainer (listed in [1]) you will receive AUH emails with Recipe upgrades when AUH detects that upgrade is needed. The development of AUH continues with adding capabilities like buildhistory support and image testing for upgraded recipes planned for Yocto 1.9 release [2], contributions are welcome the code can be found at [3]. Any comment or concern please contact me. Cheers, alimon [1] http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-yocto/conf/distro/include/maintainers.inc [2] https://bugzilla.yoctoproject.org/buglist.cgi?product=Maintenance%20Toolscomponent=Automated%20Update%20Handler [3] http://git.yoctoproject.org/cgit/cgit.cgi/auto-upgrade-helper/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] is there a doc section on yocto distribution creation/versioning?
is there a recommended workflow for tagging/versioning one's own builds from yocto? that is, given the collection of layers that might go into one's local builds, in order to properly version your builds for release, one would have to keep track of not only the checkouts of the various layers, but any local fixes added to them, combined with all of the local conf settings used for that build, and so on. is there a writeup on this? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] is there a doc section on yocto distribution creation/versioning?
Robert, -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto- boun...@yoctoproject.org] On Behalf Of Robert P. J. Day Sent: Thursday, June 25, 2015 6:29 AM To: Yocto discussion list Subject: [yocto] is there a doc section on yocto distribution creation/versioning? is there a recommended workflow for tagging/versioning one's own builds from yocto? that is, given the collection of layers that might go into one's local builds, in order to properly version your builds for release, one would have to keep track of not only the checkouts of the various layers, but any local fixes added to them, combined with all of the local conf settings used for that build, and so on. is there a writeup on this? If there is a writeup on this I have not seen it. I've developed a workflow on my own for our setup that works okay. Whether it'd be a recommended workflow or not is a different question. We have a local Git server which houses our clones of the yocto/oe layers and our own layers. We are on the dizzy branch now, so we have a local dizzy branch on our Git servers that are a clone of the official repos with a few extra commits (I believe there were a few master patches we incorporated to fix some issues we were seeing). We then have two layers of our own. One layer is a public layer and the other is a private layer. The public layer contains our base image recipe and all the bbappends for yocto/oe recipes to setup the image the way we want. The private layer has our proprietary applications and then a bbappend for the image to add the proprietary applications. This way we can do a build without our private layer to ensure we aren't accidentally deploying any proprietary code for FOSS compliance. We have an autobuilder setup to build the public image and the full image to verify both builds are working. We also have a distribution recipe similar to the angstrom-version recipe that Angstrom uses for its distribution versioning. This is how our system can tell which distribution version it is on and report it to the user. When we do a new distribution release, we tag all the layers with the distribution version name and commit the tags to our local Git server. Then we can retrieve all our local layers based up on a tag and get back to a specific release if we need to. If anyone else has a different method that they think works better, I'd love to hear it. -Bryan rday -- == == Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday == == -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] is there a doc section on yocto distribution creation/versioning?
On Thu, 25 Jun 2015, Bryan Evenson wrote: Robert, -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto- boun...@yoctoproject.org] On Behalf Of Robert P. J. Day Sent: Thursday, June 25, 2015 6:29 AM To: Yocto discussion list Subject: [yocto] is there a doc section on yocto distribution creation/versioning? is there a recommended workflow for tagging/versioning one's own builds from yocto? that is, given the collection of layers that might go into one's local builds, in order to properly version your builds for release, one would have to keep track of not only the checkouts of the various layers, but any local fixes added to them, combined with all of the local conf settings used for that build, and so on. is there a writeup on this? If there is a writeup on this I have not seen it. I've developed a workflow on my own for our setup that works okay. Whether it'd be a recommended workflow or not is a different question. ... snip ... backing up just a bit, i'm *assuming* this is a reasonable question to ask, yes? if one wants to build for a custom product, one assumes that product will have versioned releases and bug-fix releases, all possibly based on some combination of different YP layers, each which might have local enhancements, and all wrapped up with custom config files. so defining a workflow to handle all this seems like a reasonable thing to ask for. i'm surprised it hasn't already been written up somewhere. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Pickup the latest changes
Hi I would like to make a Yocto recipe that picks up a package from the server that has the latest timestamp. It has the same filename but, differnt timestamp, how do instruct my recipe to check the timestmp of the tar.bz2 file and try to get the latest? thanks Andy -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi][PATCH] firmware.inc: Fetch a zip instead of cloning a git repo
GitHub provides this ability to download repository contents at
a specified changeset as a zip file. This is generally *much* quicker
than fetching the entire git repository.
This resolves some do_fetch() failures I've seen for bcm2835-bootfiles
in which the clone operation takes a very long time, and the connection
eventually hangs and errors out.
Signed-off-by: Jon Szymaniak jon.szyman...@gmail.com
---
recipes-bsp/common/firmware.inc | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/recipes-bsp/common/firmware.inc b/recipes-bsp/common/firmware.inc
index ad3176a..5830bb0 100644
--- a/recipes-bsp/common/firmware.inc
+++ b/recipes-bsp/common/firmware.inc
@@ -1,8 +1,10 @@
RPIFW_SRCREV ?= e42a747e8d5c4a2fb3e837d0924c7cc3936a
RPIFW_DATE ?= 20150206
-RPIFW_SRC_URI ?=
git://github.com/raspberrypi/firmware.git;protocol=git;branch=master
-RPIFW_S ?= ${WORKDIR}/git
+RPIFW_SRC_URI ?=
https://github.com/raspberrypi/firmware/archive/${RPIFW_SRCREV}.zip;
+RPIFW_S ?= ${WORKDIR}/firmware-${RPIFW_SRCREV}
SRC_URI = ${RPIFW_SRC_URI}
+SRC_URI[md5sum] = a0cd8bc3a82fa708e26da62350fcf485
+SRC_URI[sha256sum] =
eebf3bbe2fda533da4b44e713090428e6c14306445543243ae03bca774894840
SRCREV = ${RPIFW_SRCREV}
PV = ${RPIFW_DATE}
--
2.1.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] cryptsetup in initramfs causes ~4 MB image size increase
I earlier wrote:
I'm interested to use an encrypted root filesystem, by using cryptsetup in
initramfs.
I'm finding that adding cryptsetup to an initramfs image increases its size by
about 4 MB. It seems that cryptsetup depends on openssl and lvm2, and
lvm2 depends on bash, and the result of that is that a lot of extra files get
dragged in.
Is this all strictly necessary? Perhaps cryptsetup really only needs
libraries,
not all of openssl and lvm2.
What would be a good way to go about reducing the dependencies that get
pulled in for cryptsetup?
I also noticed that libgcrypt could possibly be used instead of openssl (by
putting in bbappend, PACKAGECONFIG = ), saving about 0.5 MB. However
libgcrypt isn't used, according to the cryptsetup bb file, because it drops
root
privileges if it is linked with libcap support. That gives the obscure
cryptsetup
error Cannot initialize device-mapper. Is dm_mod kernel module loaded?
when trying to use cryptsetup with libgcrypt. Is there any reasonable work-
around for this?
I found that I can cut it down significantly, using the following
lvm2_2.%.bbappend:
---
PACKAGES =+ lvm2-libdevmapper
# ${base_libdir}/udev ${sbindir}/dmsetup are to get device mapper udev rules,
# to avoid cryptsetup luksOpen hanging.
FILES_lvm2-libdevmapper = ${libdir}/libdevmapper.so.* ${base_libdir}/udev
${sbindir}/dmsetup
RDEPENDS_lvm2-libdevmapper = bash
RDEPENDS_${PN} += lvm2-libdevmapper
RPROVIDES_${PN}-dev = lvm2-libdevmapper-dev
---
That cuts out a bunch of unneeded lvm files.
I'm not sure why there needs to be a bash dependency, but it didn't work
without it. I'd like to get rid of bash if it's possible.
(After reading more about libgcrypt, I think I'll just stick with openssl. It
seems questionable design for the library, to drop an application's
capabilities.)
--
Craig McQueen
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-security][PATCH] samhain-server: fix build warn
WARNING: QA Issue: /etc/init.d/samhain-server_samhain-server contained in
package samhain-server requires /bin/bash, but no providers found in its
RDEPENDS [file-rdeps]
Signed-off-by: Bian Naimeng bia...@cn.fujitsu.com
---
recipes-security/samhain/samhain-server_3.1.5.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/recipes-security/samhain/samhain-server_3.1.5.bb
b/recipes-security/samhain/samhain-server_3.1.5.bb
index fd6da3d..b8ea248 100644
--- a/recipes-security/samhain/samhain-server_3.1.5.bb
+++ b/recipes-security/samhain/samhain-server_3.1.5.bb
@@ -47,4 +47,4 @@ FILES_${PN}-dbg += \
${sbindir}/.debug/* \
-DEPENDS_${PN} += gmp bash
+RDEPENDS_${PN} += gmp bash
--
1.8.4.2
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-cgl][RFC]upgrade resource-agents
Hi all We have a recipe named cluster-resource-agents_1.0.3.bb which is a implementation for OCF Resource Agents, Is it same as Resource Agents which is being maintained in https://github.com/ClusterLabs/resource-agents. If so, the cluster-resource-agents_1.0.3.bb is too old, I want to upgrade it to the latest version. Thanks Bian -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
